Use cases

CloudNativePG has been designed to work with applicationsthat reside in the same Kubernetes cluster, for a full cloud nativeexperience.

However, it might happen that, while the database can be hostedinside a Kubernetes cluster, applications cannot be containerizedat the same time and need to run in a traditional environment such as a VM.

Case 1: Applications inside Kubernetes

In a typical situation, the application and the database run in the samenamespace inside a Kubernetes cluster.

Application and Database inside Kubernetes

The application, normally stateless, is managed as a standard Deployment ,with multiple replicas spread over different Kubernetes node, and internallyexposed through a ClusterIP service.

The service is exposed externally to the end user through an Ingress and theprovider’s load balancer facility, via HTTPS.

The application uses the backend PostgreSQL database to keep track of the statein a reliable and persistent way. The application refers to the read-writeservice exposed by the Cluster resource defined by CloudNativePG,which points to the current primary instance, through a TLS connection. The Cluster resource embeds the logic of single primary and multiple standbyarchitecture, hiding the complexity of managing a high availability cluster inPostgres.

Close-up view of application and database inside Kubernetes

Case 2: Applications outside Kubernetes

Another possible use case is to manage your PostgreSQL database insideKubernetes, while having your applications outside of it (for example in avirtualized environment). In this case, PostgreSQL is represented by an IPaddress (or host name) and a TCP port, corresponding to the defined Ingressresource in Kubernetes.

The application can still benefit from a TLS connection to PostgreSQL.

Application outside Kubernetes