Introducing: Multi-cloud Deployments in EDB Postgres for Kubernetes with Replica Clusters

EDB is proud to announce the release of EDB Postgres for Kubernetes 1.8.0! EDB Postgres for Kubernetes is a Kubernetes operator for PostgreSQL and EDB Postgres Advanced databases, which utilizes a primary/standby architecture.

Replica clusters

The most important feature introduced in version 1.8.0 is represented by Replica Clusters. A replica cluster is very similar to a regular Cluster resource deployed with EDB Postgres for Kubernetes. The main difference is that a replica cluster is in continuous recovery mode (that is: replica using the PostgreSQL lingo) from a selected PostgreSQL cluster, normally residing in a different Kubernetes cluster.

Replica clusters are very important from an architectural point of view, as they enhance the disaster recovery posture of a PostgreSQL database while enabling multi-cluster deployments in private, public, hybrid, or even multi-cloud contexts.

The diagram below shows an example of a replica cluster in a separate Kubernetes cluster.

There are two main phases in a replica clusters:

1. The initial setup, or bootstrap
2. The continuous replay of transactional information contained in the WAL (fed from the source cluster over the network)

The bootstrap phase can be done via either a streaming replication connection (using the pg_basebackup bootstrap method), or an S3/Azure Storage compatible object store containing a previously generated backup with Barman Cloud (using the recovery method). While the first method requires a secure and permanent connection between the two Kubernetes clusters, the latter only needs that the replica cluster has read-only access to the backup objects (specifically the base backup and the WAL archive).

Similarly, when it comes to WAL feeding, the replica cluster can rely on the streaming connection (using primary_conninfo), the object store (using barman-cloud-wal-restore in the restore_command), or any of the two—as natively and automatically supported by PostgreSQL when both primary_conninfo and restore_command are defined.
 

Monitoring enhancements

Thanks to the enhancements in both monitoring and logging introduced in the last couple of months, EDB now assesses EDB Postgres for Kubernetes to level 5 of the Operator Capability Level framework from Operator SDK. The features I am referring to are the built-in Prometheus exporter with user defined metrics, and the redirection of all logs to standard output in JSON format (including audit logs).

Version 1.8.0 introduces a few automatically collected metrics for PostgreSQL, such as:

• Number of WAL files and total size on disk
• Number of .ready in .done files in the archive status folder
• Flag for replica mode
• Number of requested minimum/maximum synchronous replicas, as well as the expected and actually observed ones

If you are planning to limit the collection of metrics for the Prometheus exporter to a specific version of PostgreSQL, or a range of versions, you’ll certainly enjoy the support for the runonserver option. Over time, you’ll be able to build a generic library of configuration files to be shared across all your Postgres installations on Kubernetes.
 

There’s more

Another neat feature introduced in EDB Postgres for Kubernetes 1.8.0 is the possibility to request taking a new backup immediately after you have configured a scheduled backup with immediate option enabled. This means that, when you create a new cluster, you can enforce taking a base backup immediately after bootstrap, ensuring Point In Time recovery capabilities from the very start of a database lifecycle.

Additionally, EDB Postgres for Kubernetes is now able to report for a single cluster the oldest consistent point in time to request a recovery, based on the backup object store’s content (in the firstRecoverabilityPoint field of the cluster’s status).

The liveness probe is now different from the readiness probe, and it is more accurate by relying on pg_isready.

As far as RedHat Openshift is concerned, we now support version 4.8, as OpenShift 4.5 is now End-Of-Life.

We are also getting ready for the release of PostgreSQL 14, having tested our software with the beta version released by the Postgres Community.

For a more detailed list of changes, please refer to the release notes for EDB Postgres for Kubernetes.

Conclusions

Version 1.8.0 is the 12th release of EDB Postgres for Kubernetes since the launch of the product in February 2021. In this timeframe, the CNP operator has been able to consistently add new features and increase stability, with resulting improvements in the areas of usability, security, administration, observability, self-healing, and availability.

You can try EDB Postgres for Kubernetes directly from your web browser by going through the Katacoda interactive demonstration in the product documentation website.

EDB Postgres for Kubernetes is available for free evaluation on all supported Kubernetes versions using the deployment manifest, OperatorHub, or a Helm chart. It is also available on OpenShift 4.6 or newer.