postgres-operator

Configuration parameters

There are two mutually-exclusive methods to set the Postgres Operator configuration.

Variable names are underscore-separated words.

ConfigMaps-based

The configuration is supplied in a key-value configmap, defined by the CONFIG_MAP_NAME environment variable. Non-scalar values, i.e. lists or maps, are encoded in the value strings using the comma-based syntax for lists and coma-separated key:value syntax for maps. String values containing ‘:’ should be enclosed in quotes. The configuration is flat, parameter group names below are not reflected in the configuration structure. There is an example

For the configmap configuration, the default parameter values mentioned here are likely to be overwritten in your local operator installation via your local version of the operator configmap. In the case you use the operator CRD, all the CRD defaults are provided in the operator’s default configuration manifest

CRD-based configuration

The configuration is stored in a custom YAML manifest. The manifest is an instance of the custom resource definition (CRD) called OperatorConfiguration. The operator registers this CRD during the start and uses it for configuration if the operator deployment manifest sets the POSTGRES_OPERATOR_CONFIGURATION_OBJECT env variable to a non-empty value. The variable should point to the postgresql-operator-configuration object in the operator’s namespace.

The CRD-based configuration is a regular YAML document; non-scalar keys are simply represented in the usual YAML way. There are no default values built-in in the operator, each parameter that is not supplied in the configuration receives an empty value. In order to create your own configuration just copy the default one and change it.

To test the CRD-based configuration locally, use the following

  kubectl create -f manifests/operatorconfiguration.crd.yaml # registers the CRD
  kubectl create -f manifests/postgresql-operator-default-configuration.yaml

  kubectl create -f manifests/operator-service-account-rbac.yaml
  kubectl create -f manifests/postgres-operator.yaml # set the env var as mentioned above

  kubectl get operatorconfigurations postgresql-operator-default-configuration -o yaml

The CRD-based configuration is more powerful than the one based on ConfigMaps and should be used unless there is a compatibility requirement to use an already existing configuration. Even in that case, it should be rather straightforward to convert the ConfigMap-based configuration into the CRD-based one and restart the operator. The ConfigMap-based configuration will be deprecated and subsequently removed in future releases.

Note that for the CRD-based configuration groups of configuration options below correspond to the non-leaf keys in the target YAML (i.e. for the Kubernetes resources the key is kubernetes). The key is mentioned alongside the group description. The ConfigMap-based configuration is flat and does not allow non-leaf keys.

Since in the CRD-based case the operator needs to create a CRD first, which is controlled by the resource_check_interval and resource_check_timeout parameters, those parameters have no effect and are replaced by the CRD_READY_WAIT_INTERVAL and CRD_READY_WAIT_TIMEOUT environment variables. They will be deprecated and removed in the future.

General

Those are top-level keys, containing both leaf keys and groups.

Postgres users

Parameters describing Postgres users. In a CRD-configuration, they are grouped under the users key.

Major version upgrades

Parameters configuring automatic major version upgrades. In a CRD-configuration, they are grouped under the major_version_upgrade key.

Kubernetes resources

Parameters to configure cluster-related Kubernetes objects created by the operator, as well as some timeouts associated with them. In a CRD-based configuration they are grouped under the kubernetes key.

Kubernetes resource requests

This group allows you to configure resource requests for the Postgres pods. Those parameters are grouped under the postgres_pod_resources key in a CRD-based configuration.

Patroni options

Parameters configuring Patroni. In the CRD-based configuration they are grouped under the patroni key.

Operator timeouts

This set of parameters define various timeouts related to some operator actions, affecting pod operations and CRD creation. In the CRD-based configuration resource_check_interval and resource_check_timeout have no effect, and the parameters are grouped under the timeouts key in the CRD-based configuration.

Those options affect the behavior of load balancers created by the operator. In the CRD-based configuration they are grouped under the load_balancer key.

AWS or GCP interaction

The options in this group configure operator interactions with non-Kubernetes objects from Amazon Web Services (AWS) or Google Cloud Platform (GCP). They have no effect unless you are using either. In the CRD-based configuration those options are grouped under the aws_or_gcp key. Note the GCP integration is not yet officially supported.

Logical backup

These parameters configure a K8s cron job managed by the operator to produce Postgres logical backups. In the CRD-based configuration those parameters are grouped under the logical_backup key.

Debugging the operator

Options to aid debugging of the operator itself. Grouped under the debug key.

Automatic creation of human users in the database

Options to automate creation of human users with the aid of the teams API service. In the CRD-based configuration those are grouped under the teams_api key.

Logging and REST API

Parameters affecting logging and REST API listener. In the CRD-based configuration they are grouped under the logging_rest_api key.

Scalyr options (deprecated)

Those parameters define the resource requests/limits and properties of the scalyr sidecar. In the CRD-based configuration they are grouped under the scalyr key. Note, that this section is deprecated. Instead, define Scalyr as a global sidecar under the sidecars key in the configuration.

Connection pooler configuration

Parameters are grouped under the connection_pooler top-level key and specify default configuration for connection pooler, if a postgres manifest requests it but do not specify some of the parameters. All of them are optional with the operator being able to provide some reasonable defaults.