Navigation :

4.3.1

Crunchy Data announces the release of the PostgreSQL Operator 4.3.1 on May 18, 2020.

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

The PostgreSQL Operator 4.3.1 release includes the following software versions upgrades:

  • The PostgreSQL containers now use versions 12.3, 11.8, 10.13, 9.6.18, and 9.5.22

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

Initial Support for SCRAM

SCRAM is a password authentication method in PostgreSQL that has been available since PostgreSQL 10 and is considered to be superior to the md5 authentication method. The PostgreSQL Operator now introduces support for SCRAM on the pgo create user and pgo update user commands by means of the --password-type flag. The following values for --password-type will select the following authentication methods:

  • --password-type="", --password-type="md5" => md5
  • --password-type="scram", --password-type="scram-sha-256" => SCRAM-SHA-256

In turn, the PostgreSQL Operator will hash the passwords based on the chosen method and store the computed hash in PostgreSQL.

When using SCRAM support, it is important to note the following observations and limitations:

  • When using one of the password modifications commands on pgo update user (e.g. --password, --rotate-password, --expires) with the desire to keep the persisted password using SCRAM, it is necessary to specify the “–password-type=scram-sha-256” directive.
  • SCRAM does not work with the current pgBouncer integration with the PostgreSQL Operator. pgBouncer presently supports only one password-based authentication type at a time. Additionally, to enable support for SCRAM, pgBouncer would require a list of plaintext passwords to be stored in a file that is accessible to it. Future work can evaluate how to leverage SCRAM support with pgBouncer.

pgo restart and pgo reload

This release introduces the pgo restart command, which allow you to perform a PostgreSQL restart on one or more instances within a PostgreSQL cluster.

You restart all instances at the same time using the following command:

pgo restart hippo

or specify a specific instance to restart using the --target flag (which follows a similar behavior to the --target flag on pgo scaledown and pgo failover):

pgo restart hippo --target=hippo-abcd

The restart itself is performed by calling the Patroni restart REST endpoint on the specific instance (primary or replica) being restarted.

As with the pgo failover and pgo scaledown commands it is also possible to specify the --query flag to query instances available for restart:

pgo restart mycluster --query

With the new pgo restart command, using --query flag with the pgo failover and pgo scaledown commands include the PENDING RESTART information, which is now returned with any replication information.

This release allows for the pgo reload command to properly reloads all instances (i.e. the primary and all replicas) within the cluster.

Dynamic Namespace Mode and Older Kubernetes Versions

The dynamic namespace mode (e.g. pgo create namespace + pgo delete namespace) provides the ability to create and remove Kubernetes namespaces and automatically add them unto the purview of the PostgreSQL Operator. Through the course of fixing usability issues with working with the other namespaces modes (readonly, disabled), a change needed to be introduced that broke compatibility with Kubernetes 1.12 and earlier.

The PostgreSQL Operator still supports managing PostgreSQL Deployments across multiple namespaces in Kubernetes 1.12 and earlier, but only with readonly mode. In readonly mode, a cluster administrator needs to create the namespace and the RBAC needed to run the PostgreSQL Operator in that namespace. However, it is now possible to define the RBAC required for the PostgreSQL Operator to manage clusters in a namespace via a ServiceAccount, as described in the Namespace section of the documentation.

The usability change allows for one to add namespace to the PostgreSQL Operator’s purview (or deploy the PostgreSQL Operator within a namespace) and automatically set up the appropriate RBAC for the PostgreSQL Operator to correctly operate.

Other Changes

  • The RBAC required for deploying the PostgreSQL Operator is now decomposed into the exact privileges that are needed. This removes the need for requiring a cluster-admin privilege for deploying the PostgreSQL Operator. Reported by (@obeyler).
  • With namespace modes disabled and readonly, the PostgreSQL Operator will now dynamically create the required RBAC when a new namespace is added if that namespace has the RBAC defined in local-namespace-rbac.yaml. This occurs when PGO_DYNAMIC_NAMESPACE is set to true.
  • If the PostgreSQL Operator has permissions to manage it’s own RBAC within a namespace, it will now reconcile and auto-heal that RBAC as needed (e.g. if it is invalid or has been removed) to ensure it can properly interact with and manage that namespace.
  • Add default CPU and memory limits for the metrics collection and pgBadger sidecars to help deployments that wish to have a Pod QoS of Guaranteed. The metrics defaults are 100m/24Mi and the pgBadger defaults are 500m/24Mi. Reported by (@jose-joye).
  • Introduce DISABLE_FSGROUP option as part of the installation. When set to true, this does not add a FSGroup to the Pod Security Context when deploying PostgreSQL related containers or pgAdmin 4. This is helpful when deploying the PostgreSQL Operator in certain environments, such as OpenShift with a restricted Security Context Constraint. Defaults to false.
  • Remove the custom Security Context Constraint (SCC) that would be deployed with the PostgreSQL Operator, so now the PostgreSQL Operator can be deployed using default OpenShift SCCs (e.g. “restricted”, though note that DISABLE_FSGROUP will need to be set to true for that). The example PostgreSQL Operator SCC is left in the examples directory for reference.
  • When PGO_DISABLE_TLS is set to true, then PGO_TLS_NO_VERIFY is set to true.
  • Some of the pgo-deployer environmental variables that we not needed to be set by a user were internalized. These include ANSIBLE_CONFIG and HOME.
  • When using the pgo-deployer container to install the PostgreSQL Operator, update the default watched namespace to pgo as the example only uses this namespace.

Fixes

  • Fix for cloning a PostgreSQL cluster when the pgBackRest repository is stored in S3.
  • The pgo show namespace command now properly indicates which namespaces a user is able to access.
  • Ensure the pgo-apiserver will successfully run if PGO_DISABLE_TLS is set to true. Reported by (@zhubx007).
  • Prevent a run of pgo-deployer from failing if it detects the existence of dependent cluster-wide objects already present.
  • Deployments with pgo-deployer using the default file with hostpathstorage will now successfully deploy PostgreSQL clusters without any adjustments.
  • Ensure image pull secrets are attached to deployments of the pgo-client container.
  • Ensure client-setup.sh executes to completion if existing PostgreSQL Operator credentials exist that were created by a different installation method
  • Update the documentation to properly name CCP_IMAGE_PULL_SECRET_MANIFEST and PGO_IMAGE_PULL_SECRET_MANIFEST in the pgo-deployer configuration.
  • Several fixes for selecting default storage configurations and sizes when using the pgo-deployer container. These include #1, #4, and #8 in the STORAGE family of variables.
  • The custom setup example was updated to reflect the current state of bootstrapping the PostgreSQL container.