Navigation :

4.1.0

Crunchy Data announces the release of PostgreSQL Operator 4.1 on October 15, 2019.

In addition to new features, such as dynamic namespace manage by the Operator and the ability to subscribe to a stream of lifecycle events that occur with PostgreSQL clusters, this release adds many new features and bug fixes.

The Postgres Operator 4.1 release also includes the following software versions upgrades:

  • The PostgreSQL now uses versions 11.5, 10.10, 9.6.15, and 9.5.19. The PostgreSQL container now includes support for PL/Python.
  • pgBackRest is now 2.17
  • pgMonitor now uses version 3.2

To build Postgres Operator 4.1, you will need to utilize buildah version 1.9.0 and above.

Postgres Operator is tested with Kubernetes 1.13 - 1.15, OpenShift 3.11+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+. At present, Postgres Operator 4.1 is not compatible with Kubernetes 1.16.

Major Features

Dynamic Namespace Management

Postgres Operator 4.1 introduces the ability to dynamically management Kubernetes namespaces from the Postgres Operator itself. Kubernetes namespaces provide the ability to isolate workloads within a Kubernetes cluster, which can provide additional security and privacy amongst users.

The previous version of the Postgres Operator allowed users to add Kubernetes namespaces to which the Postgres Operator could deploy and manage clusters. Postgres Operator 4.1 expands on this ability by allowing the Operator to dynamically add and remove namespaces using the pgo create namespace and pgo delete namespace commands.

This allows for several different deployment patterns for PostgreSQL clusters, including:

  • Deploying PostgreSQL clusters within a single namespace for an individual user
  • Deploying a PostgreSQL cluster into its own namespace

Note that deleting a namespace in Kubernetes deletes all of the objects that reside within that namespace, including active PostgreSQL clusters. Ensure that you wish to delete everything inside a namespace before executing pgo delete namespace.

This has also lead to a change in terms of how role-based access control (RBAC) is handled. Traditionally, RBAC permissions we added to the ClusterRole objects, but in order to support dynamic namespace management, the RBAC has been moved to the Role objects.

If you would like to use the dynamic namespace feature Kubernetes 1.11 and OpenShift 3.11, you will also need to utilize the add-targeted-namespace.sh script that is bundled with Postgres Operator 4.1. To add a namespace to dynamically to your Postgres Operator deployment in Kubernetes 1.11, you first need to create the namespace with kubectl (e.g. kubectl create namespace yournamespace) and then run the add-targeted-namespace.sh script (./add-targeted-namespace.sh yournamespace).

Lifecycle Events

Postgres Operator 4.1 now provides PostgreSQL lifecycle events that occur during the operation of a cluster. Lifecycle events include things such as when a cluster is provisioned, a replica is added, a backup is taken, a cluster fails over, etc. Each deployed PostgreSQL cluster managed by the PostgreSQL Operator will report back to the Operator around these lifecycle events via the NSQ distributed messaging platform.

You can subscribe to lifecycle events by topic using the pgo watch command. For subscribe to all events for clusters under management, you can run pgo watch alltopic. Eventing can be disabled using the DISABLE_EVENTING environmental variable within the postgres-operator deployment.

For more information, please read the Eventing section of the documentation.

Breaking Changes

Containers

  • The node_exporter container is no longer shipped with the PostgreSQL Operator. A detailed explanation of how node-style metrics are handled is available in the “Additional Features” section.

API

  • The pgo update cluster API endpoint now uses a HTTP POST instead of GET
  • The user management endpoints (e.g. pgo create user) now use a HTTP POST instead of a GET.

Command-line interface

  • Removed the -db flag from pgo create user and pgo update user
  • Removed --update-password flag from the pgo user command

Installation

  • Changed the Ansible installer to use uninstall and uninstall-metrics tags instead of deprovision and deprovision-metrics respectively

Builds

  • The Makefile now uses buildah for building the containers instead of Docker. The PostgreSQL Operator can be built with buildah v1.9.0 and above.

Additional Features

General PostgreSQL Operator Features

  • PostgreSQL Operator users and roles can now be dynamically managed (i.e. pgouser and pgorole)

  • Readiness probes have been added to the apiserver and scheduler and is now included in the new event container. The scheduler uses a special heartbeat task to provide its readiness.

  • Added the DISABLE_TLS environmental variable for apiserver, which allows the API server to run over HTTP.

  • Added the NOAUTH_ROUTES environmental variable for apiserver, which allows useres to bypass TLS authentication on certain routes (e.g. /health). At present, only /health can be used in this variable.

  • Services ports for the postgres_exporter and pgBadger are now templated so a user can now customize them beyond the defaults.

PostgreSQL Upgrade Management

  • The process to perform a minor upgrade on a PostgreSQL deployment was modified in order to minimize downtime. Now, when a pgo upgrade cluster command is run, the PostgreSQL Operator will upgrade all the replicas to the desired version of PostgreSQL before upgrading the primary container. If autofail is enabled, the PostgreSQL Operator will failover to a pod that is already updated to a newer version, which minimizes downtime and allows the cluster to upgrade to the desired, updated version of PostgreSQL.

  • pgo upgrade now supports the --all flag, which will upgrade every single PostgreSQL cluster managed by the PostgreSQL Operator (i.e. pgo upgrade --all)

PostgreSQL User Management

  • All user passwords are now loaded in from Kubernetes Secrets.
  • pgo create user --managed now supports any acceptable password for PostgreSQL
  • Improved error message for calling the equivalent pgo show user command when interfacing with the API directly and there are no clusters found for th euser.

Monitoring

  • Updated the Grafana dashboards to use those found in pgMonitor v3.2
  • The crunchy-collect container now connects to PostgreSQL using a password that is stored in a Kubernetes secret
  • Introduced support for collecting host-style metrics via the cAdvisor installations that are installed and running on each Kubelet. This requires for the ClusterRole to have the nodes and nodes/metrics resources granted to it.

Logging

  • Updated logging to provide additional details of where issues occurred, including file and line number where the issue originated.

Installation

  • The Ansible installer uninstall tag now has the option of preserving portions of the previous installation
  • The Ansible installer supports NFS and hostpath storage options
  • The Ansible installer can now set the fsgroup for the metrics tag
  • The Ansible installer now has the same configuration options as the bash installer
  • The Ansible installer now supports a separate RBAC installation
  • Add a custom security context constraint (SCC) to the Ansible and bash installers that is applied to pods created by the Operator. This makes it possible to customize the control permissions for the PostgreSQL cluster pods managed by the Operator

Fixes

  • Fixed a bug where testuser was always created even if the username was modified in the pgo.yaml
  • Fixed the --expired flag for pgo show user to show the number of days until a user’s password expires
  • Fixed the workflow for pgo benchmark jobs to show completion
  • Modify the create a cluster via a custom resource definition (CRD) to use pgBackRest
  • Fixed an issue with the pgpool label when a pg_dump is performed by calling the REST API
  • Fixed the pgo load example, which previous used a hardcoded namespace. This has changed with the support of dynamic namespaces.