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+.
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:
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.
--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
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 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 (
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.
- 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-adminprivilege for deploying the PostgreSQL Operator. Reported by (@obeyler).
- With namespace modes
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_NAMESPACEis set to
- 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).
DISABLE_FSGROUPoption 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
restrictedSecurity Context Constraint. Defaults to
- 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_FSGROUPwill need to be set to
truefor that). The example PostgreSQL Operator SCC is left in the
examplesdirectory for reference.
PGO_DISABLE_TLSis set to
PGO_TLS_NO_VERIFYis set to
- Some of the
pgo-deployerenvironmental variables that we not needed to be set by a user were internalized. These include
- When using the
pgo-deployercontainer to install the PostgreSQL Operator, update the default watched namespace to
pgoas the example only uses this namespace.
- Fix for cloning a PostgreSQL cluster when the pgBackRest repository is stored in S3.
pgo show namespacecommand now properly indicates which namespaces a user is able to access.
- Ensure the
pgo-apiserverwill successfully run if
PGO_DISABLE_TLSis set to
true. Reported by (@zhubx007).
- Prevent a run of
pgo-deployerfrom failing if it detects the existence of dependent cluster-wide objects already present.
- Deployments with
pgo-deployerusing the default file with
hostpathstoragewill now successfully deploy PostgreSQL clusters without any adjustments.
- Ensure image pull secrets are attached to deployments of the
client-setup.shexecutes to completion if existing PostgreSQL Operator credentials exist that were created by a different installation method
- Update the documentation to properly name
- Several fixes for selecting default storage configurations and sizes when using the
pgo-deployercontainer. These include #1, #4, and #8 in the
STORAGEfamily of variables.
- The custom setup example was updated to reflect the current state of bootstrapping the PostgreSQL container.