Navigation :

4.3.2

Crunchy Data announces the release of the PostgreSQL Operator 4.3.2 on May 27, 2020.

The PostgreSQL Operator is released in conjunction with the Crunchy Container Suite.

Version 4.3.2 of the PostgreSQL Operator contains bug fixes to the installer container and changes to how CPU/memory requests and limits can be specified.

PostgreSQL Operator is tested with Kubernetes 1.13 - 1.18, OpenShift 3.11+, OpenShift 4.3+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+.

Changes

Resource Limit Flags

PostgreSQL Operator 4.3.0 introduced some new options to tune the resource requests for PostgreSQL instances under management and other associated deployments, including pgBackRest and pgBouncer. From some of our learnings of running PostgreSQL in Kubernetes, we heavily restricted how the limits on the Pods could be set, and tied them to be the same as the requests.

Due to feedback from a variety of sources, this caused more issues than it helped, and as such, we decided to introduce a breaking change into a patch release and remove the --enable-*-limit and --disable-*-limit series of flags and replace them with flags that allow you to specifically choose CPU and memory limits.

This release introduces several new flags to various commands, including:

  • pgo create cluster --cpu-limit
  • pgo create cluster --memory-limit
  • pgo create cluster --pgbackrest-cpu-limit
  • pgo create cluster --pgbackrest-memory-limit
  • pgo create cluster --pgbouncer-cpu-limit
  • pgo create cluster --pgbouncer-memory-limit
  • pgo update cluster --cpu-limit
  • pgo update cluster --memory-limit
  • pgo update cluster --pgbackrest-cpu-limit
  • pgo update cluster --pgbackrest-memory-limit
  • pgo create pgbouncer --cpu-limit
  • pgo create pgbouncer --memory-limit
  • pgo update pgbouncer --cpu-limit
  • pgo update pgbouncer --memory-limit

Additionally, these values can be modified directly in a pgcluster Custom Resource and the PostgreSQL Operator will react and make the modifications.

Other Changes

  • The pgo-deployer container can now run using an aribtrary UID.
  • For deployments of the PostgreSQL Operator using the pgo-deployer container to OpenShift 3.11 environments, a new template YAML file, postgresql-operator-ocp311.yml is provided. This YAML file requires that the pgo-deployer is run with cluster-admin role for OpenShift 3.11 environments due to the lack of support of the escalate RBAC verb. Other environments (e.g. Kubernetes, OpenShift 4+) still do not require cluster-admin.
  • Allow for the resumption of download the pgo client if the client-setup.sh script gets interrupted. Contributed by Itay Grudev (@itay-grudev).

Fixes

  • The pgo-deployer container now assigns the required Service Account all the appropriate get RBAC privileges via the postgres-operator.yml file that it needs to properly install. This allows the install functionality to properly work across multiple runs.
  • For OpenShift deploymments, the pgo-deployer leverages version 4.4 of the oc client.
  • Use numeric UIDs for users in the PostgreSQL Operator management containers to support MustRunAsNonRoot Pod Security Policies and the like. Reported by Olivier Beyler (@obeyler).