postgres-operator

Cluster manifest reference

Individual Postgres clusters are described by the Kubernetes cluster manifest that has the structure defined by the postgresql CRD (custom resource definition). The following section describes the structure of the manifest and the purpose of individual keys. You can take a look at the examples of the minimal and the complete cluster manifests.

When Kubernetes resources, such as memory, CPU or volumes, are configured, their amount is usually described as a string together with the units of measurements. Please, refer to the Kubernetes documentation for the possible values of those.

:exclamation: If both operator configmap/CRD and a Postgres cluster manifest define the same parameter, the value from the Postgres cluster manifest is applied.

Manifest structure

A Postgres manifest is a YAML document. On the top level both individual parameters and parameter groups can be defined. Parameter names are written in camelCase.

Cluster metadata

Those parameters are grouped under the metadata top-level key.

Top-level parameters

These parameters are grouped directly under the spec key in the manifest.

Prepared Databases

The operator can create databases with default owner, reader and writer roles without the need to specifiy them under users or databases sections. Those parameters are grouped under the preparedDatabases top-level key. For more information, see user docs.

Postgres parameters

Those parameters are grouped under the postgresql top-level key, which is required in the manifest.

Patroni parameters

Those parameters are grouped under the patroni top-level key. See the Patroni documentation for the explanation of ttl and loop_wait parameters.

Postgres container resources

Those parameters define CPU and memory requests and limits for the Postgres container. They are grouped under the resources top-level key with subgroups requests and limits.

Requests

CPU and memory requests for the Postgres container.

Limits

CPU and memory limits for the Postgres container.

Parameters defining how to clone the cluster from another one

Those parameters are applied when the cluster should be a clone of another one that is either already running or has a basebackup on S3. They are grouped under the clone top-level key and do not affect the already running cluster.

Standby cluster

On startup, an existing standby top-level key creates a standby Postgres cluster streaming from a remote location - either from a S3 or GCS WAL archive or a remote primary. Only one of options is allowed and required if the standby key is present.

Volume properties

Those parameters are grouped under the volume top-level key and define the properties of the persistent storage that stores Postgres data.

Sidecar definitions

Those parameters are defined under the sidecars key. They consist of a list of dictionaries, each defining one sidecar (an extra container running along the main Postgres container on the same pod). The following keys can be defined in the sidecar dictionary:

Requests

CPU and memory requests for the sidecar container.

Limits

CPU and memory limits for the sidecar container.

Connection pooler

Parameters are grouped under the connectionPooler top-level key and specify configuration for connection pooler. If this section is not empty, a connection pooler will be created for master service only even if enableConnectionPooler is not present. But if this section is present then it defines the configuration for both master and replica pooler services (if enableReplicaConnectionPooler is enabled).

Custom TLS certificates

Those parameters are grouped under the tls top-level key. Note, you have to define spiloFSGroup in the Postgres cluster manifest or spilo_fsgroup in the global configuration before adding the tls section’.

Change data capture streams

This sections enables change data capture (CDC) streams via Postgres’ logical decoding feature and pgoutput plugin. While the Postgres operator takes responsibility for providing the setup to publish change events, it relies on external tools to consume them. At Zalando, we are using a workflow based on Debezium Connector which can feed streams into Zalando’s distributed event broker Nakadi among others.

The Postgres Operator creates custom resources for Zalando’s internal CDC operator which will be used to set up the consumer part. Each stream object can have the following properties: