4.3.0 Beta 2

Crunchy Data announces the release of the 'PostgreSQL Operator 4.3.0 Beta 2](https://www.crunchydata.com/developers/download-postgres/containers/postgres-operator).

Changes since Beta 1:

Breaking Changes

• "Limit" resource parameters are no longer set on the containers, in particular, the PostgreSQL container, due to undesired behavior stemming from the host machine OOM killer. Further details can be found in the original pull request.
• Added DefaultInstanceMemory, DefaultBackrestMemory, and DefaultPgBouncerMemory options to the pgo.yaml configuration to allow for the setting of default memory requests for PostgreSQL instances, the pgBackRest repository, and pgBouncer instances respectively.
• If unset by either the PostgreSQL Operator configuration or one-off, the default memory resource requests for the following applications are:
  • PostgreSQL: 512Mi
  • pgBackRest: 48Mi
  • pgBouncer: 24Mi
• Remove the Default...ContainerResources set of parameters from the pgo.yaml configuration file.
• Remove the PreferredFailoverNode feature, as it had already been effictively removed.
• Remove explicit rm calls when cleaning up PostgreSQL clusters. This behavior is left to the storage provsioner that one deploys with their PostgreSQL instances

Features

Elimination of ClusterRole Requirement for the PostgreSQL Operator

PostgreSQL Operator 4.0 introduced the ability to manage PostgreSQL clusters
across multiple Kubernetes Namespaces. PostgreSQL Operator 4.1 built on this
functionality by allowing users to dynamically control which Namespaces it
managed as well as the PostgreSQL clusters deployed to them. In order to
leverage this feature, one must grant a ClusterRole
level permission via a ServiceAccount to the PostgreSQL Operator.

There are a lot of deployment environments for the PostgreSQL Operator that only
need for it to exists within a single namespace and as such, granting
cluster-wide privileges is superfluous, and in many cases, undesirable. As such,
it should be possible to deploy the PostgreSQL Operator to a single namespace
without requiring a ClusterRole.

To do this, but maintain the aforementioned Namespace functionality for those
who require it, PostgreSQL Operator 4.3 introduces the ability to opt into
deploying it with minimum required ClusterRole privileges and in turn, the
ability to deploy the PostgreSQL Operator without a ClusterRole. To do so, the
PostgreSQL Operator introduces the concept of "namespace operating mode" which
lets one select the type deployment to create. The namespace mode is set at the
install time for the PostgreSQL Operator, and files into one of three options:

• dynamic: This is the default. This enables full dynamic Namespace
  management capabilities, in which the PostgreSQL Operator can create, delete and
  update any Namespaces within the Kubernetes cluster, while then also having the
  ability to create the Roles, Role Bindings and Service Accounts within those
  Namespaces for normal operations. The PostgreSQL Operator can also listen for
  Namespace events and create or remove controllers for various Namespaces as
  changes are made to Namespaces from Kubernetes and the PostgreSQL Operator's
  management.

• readonly: In this mode, the PostgreSQL Operator is able to listen for
  namespace events within the Kubernetetes cluster, and then manage controllers
  as Namespaces are added, updated or deleted. While this still requires a
  ClusterRole, the permissions mirror those of a "read-only" environment, and as
  such the PostgreSQL Operator is unable to create, delete or update Namespaces
  itself nor create RBAC that it requires in any of those Namespaces. Therefore,
  while in readonly, mode namespaces must be preconfigured with the proper RBAC
  as the PostgreSQL Operator cannot create the RBAC itself.

• disabled: Use this mode if you do not want to deploy the PostgreSQL Operator
  with any ClusterRole privileges, especially if you are only deploying the
  PostgreSQL Operator to a single namespace. This disables any Namespace
  management capabilities within the PostgreSQL Operator and will simply attempt
  to work with the target Namespaces specified during installation. If no target
  Namespaces are specified, then the Operator will be configured to work within
  the namespace in which it is deployed. As with the readonly mode, while in
  this mode, Namespaces must be pre-configured with the proper RBAC, since the
  PostgreSQL Operator cannot create the RBAC itself.

Based on the installer you use, the variables to set this mode are either named:

• PGO_NAMESPACE_MODE
• namespace_mode

pgo-installer Improvements

The new pgo-installer container can now be run directly from kubectl, i.e.

kubectl apply -f /path/to/install.yml

Other New Features

• pgo create cluster now supports the --pgbackrest-storage-config flag to specify specific a specific storage configuration for the pgBackRest repository in a cluster
• pgo create cluster now supports the --pgbackrest-cpu, --pgbackrest-memory, --pgbouncer-cpu, and --pgbouncer-memory resource request flags for the pgBackRest repository and the pgBouncer instances respectively.
• pgo create pgbouncer now supports the --cpu, and --memory resource request flags for requesting container resources for the pgBouncer instances
• pgo update cluster now supports the --pgbackrest-cpu, --pgbackrest-memory resource request flags for modifying container resources for the pgBackRest repository.
• pgo update pgbouncer now supports the --cpu, and --memory resource request flags for requesting container resources for the pgBouncer instances.
• Specify a different S3 Certificate Authority (CA) with pgo create cluster by using the --pgbackrest-s3-ca-secret flag, which refers to an existing Secret that contains a key called aws-s3-ca.crt that contains the CA. Reported by Aurelien Marie @(aurelienmarie)

Fixes

• Default the recovery action to "promote" when performing a "point-in-time-recovery" (PITR), which will ensure that a PITR process completes.
• Fix performance degradation discovered in certain environments that use the dynamic Namespace feature. Reported by (@dadez)
• Remove backoffLimit from Jobs that can be retried, which is most of them. Reported by Leo Khomenko (@lkhomenk)