Crunchy Data announces the release of Crunchy Postgres for Kubernetes 5.1.0.
Crunchy Postgres for Kubernetes is powered by PGO, the open source Postgres Operator from Crunchy Data. PGO is released in conjunction with the Crunchy Container Suite.
Crunchy Postgres for Kubernetes 5.1.0 includes the following software versions upgrades:
- Patroni is now at version 2.1.3.
- pgAdmin 4 is now at version 4.30
- pgBackRest is updated to version 2.38.
- The pgAudit extension is now at version 1.6.2 (PG 14), 1.5.2 (PG 13), 1.4.3 (PG 12), 1.3.4 (PG 11) & 1.2.4 (PG 10).
- The pgnodemx extension is now at version 1.3.0.
- The TimescaleDB extension is now at version 2.6.0.
Read more about how you can get started with Crunchy Postgres for Kubernetes. We recommend forking the Postgres Operator examples repo.
pgAdmin 4 Integration
PGO v5.1 reintroduces the pgAdmin 4 integration from PGO v4. v5.1 adds the
spec.userInterace.pgAdmin section to the
PostgresCluster custom resource to enable pgAdmin 4 integration for a Postgres cluster. Any users defined in
spec.users are are synced with pgAdmin 4, allowing for a seamless management experience.
Please see the pgAdmin 4 section of the PGO documentation for more information about this integration.
Removal of SSH Requirement for Local Backups
Previous versions of PGO relied on the use of
ssh to take backups and store archive files on Kubernetes-managed storage. PGO v5.1 now uses mTLS to securely transfer and manage these files.
The upgrade to pgBackRest TLS is seamless and transparent if using related image environment variables with your PGO Deployment (please see the PostgresCluster CRD reference for more information). This is because PGO will automatically handle updating all image tags across all existing PostgresCluster’s following the upgrade to v5.1, seamlessly rolling out any new images as required for proper pgBackRest TLS functionality.
If you are not using related image environment variables, and are instead explicitly defining images via the
image fields in your PostgresCluster spec, then an additional step is required in order to ensure a seamless upgrade. Specifically, all
postgrescluster.spec.backups.pgbackrest.image fields must first be updated to specify images containing pgBackRest 2.38. Therefore, prior to upgrading, please update all
postgrescluster.spec.backups.pgbackrest.image fields to the latest versions of the
crunchy-pgbackrest containers available per the Components and Compatibility guide (please note that the
crunchy-postgres container should be updated to the latest version available for the major version of PostgreSQL currently being utilized within a cluster).
In the event that PGO is upgraded to v5.1 before updating your image tags, simply update any
image fields in your PostgresCluster spec as soon as possible following the upgrade.
- Set Pod Disruption Budgets (PDBs) for both Postgres and PgBouncer instances.
- Postgres configuration changes requiring a database restart are now automatically rolled out to all instances in the cluster.
- Do not recreate instance Pods for changes that only require a Postgres restart. These types of changes are now applied more quickly.
- Support for manual switchovers or failovers.
- Rotate PgBouncer TLS certificates without downtime.
- Add support for using Active Directory for securely authenticating with PostgreSQL using the GSSAPI.
- Support for using AWS IAM roles with S3 with backups when PGO is deployed in EKS.
- The characters used for password generation can now be controlled using the
postgrescluster.spec.users.password.typeparameter. Choices are
ASCII; defaults to
- Introduction for automatically checking for updates for PGO and Postgres components. If an update is discovered, it is included in the PGO logs.
- As a result of a fix in PgBouncer v1.16, PGO no longer sets verbosity settings in the PgBouncer configuration to catch missing
%includedirectives. Users can increase verbosity in their own configuration files to maintain the previous behavior.
- The Postgres
archive_timeoutsetting now defaults to 60 seconds (
60s), which matches the behavior from PGO v4. If you do not require for WAL files to be generated once a minute (e.g. generally idle system where a window of data-loss is acceptable or a development system), you can set this to
spec: patroni: dynamicConfiguration: postgresql: parameters: archive_timeout: 0
- All Pods now have
falsein order to ensure injected environment variables do not conflict with the various applications running within.
- The names of CronJobs created for scheduled backups are shortened to
<cluster name>-<repo#>-<backup type>to allow for longer PostgresCluster names.