postgres-operator

Configuration parameters

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

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.

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

Variable names are underscore-separated words.

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.

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.