Crunchy Data announces the release of the PGO, the open source Postgres Operator, 5.0.0 on June 30, 2021.
To get started with PGO 5.0.0, we invite you to read through the quickstart. We also encourage you to work through the PGO tutorial.
PGO 5.0.0 is a major release of the Postgres Operator. The focus of this release was to take the features from the previous versions of PGO, add in some new features, and allow you to deploy Kubernetes native Postgres through a fully declarative, GitOps style workflow. As with previous versions, PGO 5.0 makes it easy to deploy production ready, cloud native Postgres.
Postgres clusters are now fully managed through a custom resource called
postgrescluster.postgres-operator.crunchydata.com. You can also view the various attributes of the custom resource using
kubectl explain postgrescluster.postgres-operator.crunchydata.com or
kubectl explain postgrescluster. The custom resource can be edited at any time, and all of the changes are rolled out in a minimally disruptive way.
There are a set of examples for how to use Kustomize and Helm with PGO 5.0. This example set will grow and we encourage you to contribute to it.
PGO 5.0 continues to support the Postgres architecture that was built up in previous releases. This means that Postgres clusters are deployed without a single-point-of-failure and can continue operating even if PGO is unavailable. PGO 5.0 includes support for Postgres high availability, backup management, disaster recovery, monitoring, full customizability, database cloning, connection pooling, security, running with locked down container settings, and more.
PGO 5.0 also continuously monitors your environment to ensure all of the components you want deployed are available. For example, if PGO detects that your connection pooler is missing, it will recreate it as you specified in the custom resource. PGO 5.0 can watch for Postgres clusters in all Kubernetes namespaces or be isolated to individual namespaces.
As PGO 5.0 is a major release, it is not backwards compatible with PGO 4.x. However, you can run PGO 4.x and PGO 5.0 in the same Kubernetes cluster, which allows you to migrate Postgres clusters from 4.x to 5.0.
Beyond being fully declarative, PGO 5.0 has some notable changes that you should be aware of. These include:
- The minimum Kubernetes version is now 1.18. The minimum OpenShift version is 4.5. This release drops support for OpenShift 3.11.
- We recommend running the latest bug fix releases of Kubernetes.
- The removal of the
pgoclient. This may be reintroduced in a later release, but all actions on a Postgres cluster can be accomplished using
oc, or your preferred Kubernetes management tool (e.g. ArgoCD).
- A fully defined
statussubresource is now available within the
postgresclustercustom resource that provides direct insight into the current status of a PostgreSQL cluster.
- Native Kubernetes eventing is now utilized to generate and record events related to the creation and management of PostgreSQL clusters.
- Postgres instances now use Kubernetes Statefulsets.
- Scheduled backups now use Kubernetes CronJobs.
- Connections to Postgres require TLS. You can bring your own TLS infrastructure, otherwise PGO provides it for you.
- Custom configurations for all components can be set directly on the
In addition to supporting the PGO 4.x feature set, the PGO 5.0.0 adds the following new features:
- Postgres minor version (bug fix) updates can be applied without having to update PGO. You only need to update the
imageattribute in the custom resource.
- Adds support for Azure Blob Storage for storing backups. This is in addition to using Kubernetes storage, Amazon S3 (or S3-equivalents like MinIO), and Google Cloud Storage (GCS).
- Allows for backups to be stored in up to four different locations simultaneously.
- Backup locations can be changed during the lifetime of a Postgres cluster, e.g. moving from “posix” to “s3”.