Crunchy Postgres for Kubernetes 5.0.x Release Notes

Release notes for each of the 5.0.x releases.

Component versions

Postgres extension versions

A bold version number indicates that the component version was updated in latest release.

5.0.9

Fixes

• With the exception of the –repo option itself, PGO no longer prevents users from specifying pgBackRest options containing the string “repo” (e.g. –repo1-retention-full).
• PGO now properly filters Jobs by namespace when reconciling restore or data migrations Job, ensuring PostgresClusters with the same name can be created within different namespaces.

5.0.8

Fixes

• A better timeout has been set for the pg_ctl start and stop commands that are run during a restore.
• A restore can now be re-attempted if PGO is unable to cleanly start or stop the database during a previous restore attempt.

5.0.7

This release contains new component and Postgres versions, but no additional fixes or changes.

5.0.6

This release contains new component and Postgres versions, but no additional fixes or changes.

5.0.5

Features

• A S3, GCS or Azure data source can now be configured when bootstrapping a new PostgresCluster. This allows existing cloud-based pgBackRest repositories to be utilized to bootstrap new clusters, while also ensuring those new clusters create and utilize their own pgBackRest repository for archives and backups (rather than writing to the repo utilized to bootstrap the cluster).
• It is now possible to configure the number of workers for the PostgresCluster controller.

Fixes

• Reduce scope of automatic OpenShift environment detection. This looks specifically for the existence of the SecurityContextConstraint API.
• An external IP is no longer copied to the primary service (e.g. hippo-primary) when the LoadBalancer service type has been configured for PostgreSQL.
• pgBackRest no longer logs to log /tmp emptyDir by default. Instead, pgBackRest logs to either the PGDATA volume (if running inside of a PG instance Pod) or a pgBackRest repository volume (if running inside a dedicated repo host Pod).
• All pgBackRest configuration resources are now copied from the source cluster when cloning a PG cluster.
• Image pull secrets are now set on directory move jobs.
• Resources are now properly set on the nss-wrapper-init container.

5.0.4

Features

• The JDBC connection string for the Postgres database and a PgBouncer instance is now available in the User Secret using jdbc-uri and pgbouncer-jdbc-uri respectively.
• Editing the password field of a User Secret now changes a password, instead of having to create a verifier.

Changes

• PostGIS is now automatically enabled when using the crunchy-postgres-gis container.
• The Downward API is mounted to the database containers.
• pgnodemx can now be enabled and used without having to enable monitoring.
• The description of the name field for an instance set now states that a name is only optional when a single instance set is defined.

Fixes

• Fix issue when performing a restore with PostgreSQL 14. Specifically, if there are mismatched PostgreSQL configuration parameters, PGO will resume replay and let PostgreSQL crash so PGO can ultimately fix it, vs. the restore pausing indefinitely.
• The pgBackRest Pod no longer automatically mounts the default Service Account. Reported by (@Shrivastava-Varsha).
• The Jobs that move data between volumes now have the correct Security Context set.
• The UBI 8 crunchy-upgrade container contains all recent PostgreSQL versions that can be upgraded.
• Ensure controller references are used for all objects that need them, instead of owner references.
• It is no longer necessary to have external WAL volumes enabled in order to upgrade a PGO v4 cluster to PGO v5 using the "Migrate From Backups" or "Migrate Using a Standby Cluster" upgrade methods.

5.0.3

Features

• The Postgres containers are renamed. crunchy-postgres-ha is now crunchy-postgres, and crunchy-postgres-gis-ha is now crunchy-postgres-gis.
• Some network filesystems are sensitive to Linux user and group permissions. Process GIDs can now be configured through PostgresCluster.spec.supplementalGroups for when your PVs don't advertise their GID requirements.
• A replica service is now automatically reconciled for access to Postgres replicas within a cluster.
• The Postgres primary service and PgBouncer service can now each be configured to have either a ClusterIP, NodePort or LoadBalancer service type. Suggested by Bryan A. S. (@bryanasdev000).
• Pod Topology Spread Constraints can now be specified for Postgres instances, the pgBackRest dedicated repository host as well as PgBouncer. Suggested by Annette Clewett.
• Default topology spread constraints are included to ensure PGO always attempts to deploy a high availability cluster architecture.
• PGO can now execute a custom SQL script when initializing a Postgres cluster.
• Custom resource requests and limits are now configurable for all init containers, therefore ensuring the desired Quality of Service (QoS) class can be assigned to the various Pods comprising a cluster.
• Custom resource requests and limits are now configurable for all Jobs created for a PostgresCluster.
• A Pod Priority Class is configurable for the Pods created for a PostgresCluster.
• An imagePullPolicy can now be configured for Pods created for a PostgresCluster.
• Existing PGDATA, Write-Ahead Log (WAL) and pgBackRest repository volumes can now be migrated from PGO v4 to PGO v5 by specifying a volumes data source when creating a PostgresCluster.
• There is now a migration guide available for moving Postgres clusters between PGO v4 to PGO v5.
• The pgAudit extension is now enabled by default in all clusters.
• There is now additional validation for PVC definitions within the PostgresCluster spec to ensure successful PVC reconciliation.
• Postgres server certificates are now automatically reloaded when they change.

Changes

• The supplemental group 65534 is no longer applied by default. Upgrading the operator will perform a rolling update on all PostgresCluster custom resources to remove it.

If you need this GID for your network filesystem, you should perform the following steps when upgrading:

1. Before deploying the new operator, deploy the new CRD. You can get the new CRD from the Postgres Operator Examples repository and executing the following command:

kubectl apply -k kustomize/install
Copy

2. Add the group to your existing PostgresCluster custom resource:

kubectl edit postgrescluster/hippo

kind: PostgresCluster … spec: supplementalGroups: - 65534 …
Copy

or

kubectl patch postgrescluster/hippo --type=merge --patch='{"spec":{"supplementalGroups":[65534]}}'
Copy

or

by modifying spec.supplementalGroups in your manifest.

3. Deploy the new operator. If you are using an up-to-date version of the manifest, you can run:

kubectl apply -k kustomize/install
Copy

• A dedicated pgBackRest repository host is now only deployed if a volume repository is configured. This means that deployments that use only cloud-based (s3, gcs, azure) repos will no longer see a dedicated repository host, nor will SSHD run in within that Postgres cluster. As a result of this change, the spec.backups.pgbackrest.repoHost.dedicated section is removed from the PostgresCluster spec, and all settings within it are consolidated under the spec.backups.pgbackrest.repoHost section. When upgrading please update the PostgresCluster spec to ensure any settings from section spec.backups.pgbackrest.repoHost.dedicated are moved into section spec.backups.pgbackrest.repoHost.
• PgBouncer now uses SCRAM when authenticating into Postgres.
• Generated Postgres certificates include the FQDN and other local names of the primary Postgres service. To regenerate the certificate of an existing cluster, delete the tls.key field from its certificate secret. Suggested by @ackerr01.

Fixes

• Validation for the PostgresCluster spec is updated to ensure at least one repo is always defined for section spec.backups.pgbackrest.repos.
• A restore will now complete successfully If max_connections and/or max_worker_processes is configured to a value higher than the default when backing up the Postgres database. Reported by Tiberiu Patrascu (@tpatrascu).
• The installation documentation now properly defines how to set the PGO_TARGET_NAMESPACE environment variable for a single namespace installation.
• Ensure the full allocation of shared memory is available to Postgres containers. Reported by Yuyang Zhang (@helloqiu).
• OpenShift auto-detection logic now looks for the presence of the SecurityContextConstraints API to avoid false positives when APIs with an openshift.io Group suffix are installed in non-OpenShift clusters. Reported by Jean-Daniel.

5.0.2

This release contains new component and Postgres versions, but no additional fixes or changes.

5.0.1

Features

• Custom affinity rules and tolerations can now be added to pgBackRest restore Jobs.
• OLM bundles can now be generated for PGO 5.

Changes

• The replicas value for an instance set must now be greater than 0, and at least one instance set must now be defined for a PostgresCluster. This is to prevent the cluster from being scaled down to 0 instances, since doing so results in the inability to scale the cluster back up.
• Refreshed the PostgresCluster CRD documentation using the latest version of crdoc (v0.3.0).
• The PGO test suite now includes a test to validate image pull secrets.
• Related Image functionality has been implemented for the OLM installer as required to support offline deployments.
• The name of the PGO Deployment and ServiceAccount has been changed to pgo for all installers, allowing both PGO v4.x and PGO v5.x to be run in the same namespace. If you are using Kustomize to install PGO and are upgrading from PGO 5.0.0, please see theUpgrade Guide for additional steps that must be completed as a result of this change in order to ensure a successful upgrade.
• PGO now automatically detects whether or not it is running in an OpenShift environment.
• Postgres users and databases can be specified in PostgresCluster.spec.users. The credentials stored in the {cluster}-pguser Secret are still valid, but they are no longer reconciled. References to that Secret should be replaced with {cluster}-pguser-{cluster}. Once all references are updated, the old {cluster}-pguser Secret can be deleted.
• The built-in postgres superuser can now be managed the same way as other users. Specifying it in PostgresCluster.spec.users will give it a password, allowing it to connect over the network.
• PostgreSQL data and pgBackRest repo volumes are now reconciled using labels.

Fixes

• It is now possible to customize shared_preload_libraries when monitoring is enabled.
• Fixed a typo in the description of the openshift field in the PostgresCluster CRD.
• When a new cluster is created using an existing PostgresCluster as its dataSource, the original primary for that cluster will now properly initialize as a replica following a switchover. This is fixed with the upgrade to Patroni 2.1.0).
• A consistent startupInstance name is now set in the PostgresCluster status when bootstrapping a new cluster using an existing PostgresCluster as its data source.
• It is now possible to properly customize the pg_hba.conf configuration file.

5.0.0

Changes

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 pgo client. This may be reintroduced in a later release, but all actions on a Postgres cluster can be accomplished using kubectl, oc, or your preferred Kubernetes management tool (e.g. ArgoCD).
• A fully defined status sub-resource is now available within the postgrescluster custom 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 postgrescluster custom resource.

Features

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 image attribute 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".