Configuration Reference

PostgreSQL Operator Installer Configuration

When installing the PostgreSQL Operator you have many configuration options, these options are listed in this section.

General Configuration

These variables affect the general configuration of the PostgreSQL Operator.

Storage Settings

The store configuration options defined in this section can be used to specify the storage configurations that are used by the PostgreSQL Operator.

Storage Configuration Options

Kubernetes and OpenShift offer support for a wide variety of different storage types and we provide suggested configurations for different environments. These storage types can be modified or removed as needed, while additional storage configurations can also be added to meet the specific storage requirements for your PostgreSQL clusters.

The following storage variables are utilized to add or modify operator storage configurations in the with the installer:

The ID portion of storage prefix for each variable name above should be an integer that is used to group the various storage variables into a single storage configuration.

Example Storage Configuration

storage3_name: 'nfsstorage'
storage3_access_mode: 'ReadWriteMany'
storage3_size: '1G'
storage3_type: 'create'
storage3_supplemental_groups: 65534

As this example storage configuration shows, integer 3 is used as the ID for each of the storage variables, which together form a single storage configuration called nfsstorage. This approach allows different storage configurations to be created by defining the proper storage variables with a unique ID for each required storage configuration.

PostgreSQL Cluster Storage Defaults

You can specify the default storage to use for PostgreSQL, pgBackRest, and other elements that require storage that can outlast the lifetime of a Pod. While the PostgreSQL Operator defaults to using default to work with the default storage class available in your environment.

Example Defaults

backrest_storage: default
backup_storage: default
primary_storage: default
replica_storage: default

With the configuration shown above, the default storage class available in the deployment environment is used.

Considerations for Multi-Zone Cloud Environments

When using the Operator in a Kubernetes cluster consisting of nodes that span multiple zones, special consideration must be taken to ensure all pods and the volumes they require are scheduled and provisioned within the same zone. Specifically, being that a pod is unable mount a volume that is located in another zone, any volumes that are dynamically provisioned must be provisioned in a topology-aware manner according to the specific scheduling requirements for the pod. For instance, this means ensuring that the volume containing the database files for the primary database in a new PostgreSQL cluster is provisioned in the same zone as the node containing the PostgreSQL primary pod that will be using it.

Default Storage Configuration Types

Default StorageClass

Host Path Storage

NFS Storage

NFS Storage Red

StorageOS

Primary Site

Alternate Site

GCE

Rook

Pod Anti-affinity Settings

This will set the default pod anti-affinity for the deployed PostgreSQL clusters. Pod Anti-Affinity is set to determine where the PostgreSQL Pods are deployed relative to each other There are three levels:

• required: Pods must be scheduled to different Nodes. If a Pod cannot be scheduled to a different Node from the other Pods in the anti-affinity group, then it will not be scheduled.
• preferred (default): Pods should be scheduled to different Nodes. There is a chance that two Pods in the same anti-affinity group could be scheduled to the same node
• disabled: Pods do not have any anti-affinity rules

The POD_ANTI_AFFINITY label sets the Pod anti-affinity for all of the Pods that are managed by the Operator in a PostgreSQL cluster. In addition to the PostgreSQL Pods, this also includes the pgBackRest repository and any pgBouncer pods. By default, the pgBackRest and pgBouncer pods inherit the value of POD_ANTI_AFFINITY, but one can override the default by setting the POD_ANTI_AFFINITY_PGBACKREST and POD_ANTI_AFFINITY_PGBOUNCER variables for pgBackRest and pgBouncer respectively

Understanding pgo_operator_namespace & namespace

The Crunchy PostgreSQL Operator can be configured to be deployed and manage a single namespace or manage several namespaces. The following are examples of different types of deployment models:

Single Namespace

To deploy the Crunchy PostgreSQL Operator to work with a single namespace (in this example our namespace is named pgo), configure the following settings:

pgo_operator_namespace: 'pgo'
namespace: 'pgo'

Multiple Namespaces

To deploy the Crunchy PostgreSQL Operator to work with multiple namespaces (in this example our namespaces are named pgo, pgouser1 and pgouser2), configure the following settings:

pgo_operator_namespace: 'pgo'
namespace: 'pgouser1,pgouser2'

Deploying Multiple Operators

The 4.0 release of the Crunchy PostgreSQL Operator allows for multiple operator deployments in the same cluster.
To install the Crunchy PostgreSQL Operator to multiple namespaces, it’s recommended to have an configuration file for each deployment of the operator.

For each operator deployment the following variables should be configured uniquely for each install.

For example, operator could be deployed twice by changing the pgo_operator_namespace and namespace for those deployments:

Install A would deploy operator to the pgo namespace and it would manage the pgo target namespace.

# Config A
pgo_operator_namespace: 'pgo'
namespace: 'pgo'
...

Install B would deploy operator to the pgo2 namespace and it would manage the pgo2 and pgo3 target namespaces.

# Config B
pgo_operator_namespace: 'pgo2'
namespace: 'pgo2,pgo3'
...

Each install of the operator will create a corresponding directory in $HOME/.pgo/<PGO NAMESPACE> which will contain the TLS and pgouser client credentials.