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.

Name Default Required Description
archive_mode true Required Set to true enable archive logging on all newly created clusters.
archive_timeout 60 Required Set to a value in seconds to configure the timeout threshold for archiving.
backrest_aws_s3_bucket Set to configure the bucket used by pgBackRest with Amazon Web Service S3 for backups and restoration in S3.
backrest_aws_s3_endpoint Set to configure the endpoint used by pgBackRest with Amazon Web Service S3 for backups and restoration in S3.
backrest_aws_s3_key Set to configure the key used by pgBackRest with Amazon Web Service S3 for backups and restoration in S3.
backrest_aws_s3_region Set to configure the region used by pgBackRest with Amazon Web Service S3 for backups and restoration in S3.
backrest_aws_s3_secret Set to configure the secret used by pgBackRest with Amazon Web Service S3 for backups and restoration in S3.
backrest_aws_s3_uri_style Set to configure whether “host” or “path” style URIs will be used when connecting to S3.
backrest_aws_s3_verify_tls Set this value to true to enable TLS verification when making a pgBackRest connection to S3.f
backrest_port 2022 Required Defines the port where pgBackRest will run.
badger false Required Set to true enable pgBadger capabilities on all newly created clusters. This can be disabled by the client.
ccp_image_prefix registry.developers.crunchydata.com/crunchydata Required Configures the image prefix used when creating containers from Crunchy Container Suite.
ccp_image_pull_secret Name of a Secret containing credentials for container image registries.
ccp_image_pull_secret_manifest Provide a path to the Secret manifest to be installed in each namespace. (optional)
ccp_image_tag centos8-13.2-4.6.1 Required Configures the image tag (version) used when creating containers from Crunchy Container Suite.
create_rbac true Required Set to true if the installer should create the RBAC resources required to run the PostgreSQL Operator.
crunchy_debug false Set to configure Operator to use debugging mode. Note: this can cause sensitive data such as passwords to appear in Operator logs.
db_name Set to a value to configure the default database name on all newly created clusters. By default, the PostgreSQL Operator will set it to the name of the cluster that is being created.
db_password_age_days 0 Set to a value in days to configure the expiration age on PostgreSQL role passwords on all newly created clusters. If set to “0”, this is the same as saying the password never expires
db_password_length 24 Set to configure the size of passwords generated by the operator on all newly created roles.
db_port 5432 Required Set to configure the default port used on all newly created clusters.
db_replicas 0 Required Set to configure the amount of replicas provisioned on all newly created clusters.
db_user testuser Required Set to configure the username of the dedicated user account on all newly created clusters.
default_instance_memory 128Mi Represents the memory request for a PostgreSQL instance.
default_pgbackrest_memory 48Mi Represents the memory request for a pgBackRest repository.
default_pgbouncer_memory 24Mi Represents the memory request for a pgBouncer instance.
delete_operator_namespace false Set to configure whether or not the PGO operator namespace (defined using variable pgo_operator_namespace) is deleted when uninstalling the PGO.
delete_watched_namespaces false Set to configure whether or not the PGO watched namespaces (defined using variable namespace) are deleted when uninstalling the PGO.
disable_auto_failover false If set, will disable autofail capabilities by default in any newly created cluster
disable_fsgroup false Set to true for deployments where you do not want to have the default PostgreSQL fsGroup (26) set. The typical usage is in OpenShift environments that have a restricted Security Context Constraints.
exporterport 9187 Required Set to configure the default port used to connect to postgres exporter.
metrics false Required Set to true enable performance metrics on all newly created clusters. This can be disabled by the client.
namespace pgo Set to a comma delimited string of all the namespaces Operator will manage.
namespace_mode dynamic Determines which namespace permissions are assigned to the PostgreSQL Operator using a ClusterRole. Options: dynamic, readonly, and disabled
pgbadgerport 10000 Required Set to configure the default port used to connect to pgbadger.
pgo_add_os_ca_store false Required When true, includes system default certificate authorities.
pgo_admin_password examplepassword Configures the pgo administrator password. When blank, a random password is generated.
pgo_admin_perms * Required Sets the access control rules provided by the PostgreSQL Operator RBAC resources for the PostgreSQL Operator administrative account that is created by this installer. Defaults to allowing all of the permissions, which is represented with the *
pgo_admin_role_name pgoadmin Required Sets the name of the PostgreSQL Operator role that is utilized for administrative operations performed by the PostgreSQL Operator.
pgo_admin_username admin Required Configures the pgo administrator username.
pgo_apiserver_port 8443 Set to configure the port used by the Crunchy PostgreSQL Operator apiserver.
pgo_apiserver_url https://postgres-operator Sets the pgo_apiserver_url for the pgo-client deployment. Note that the URL should not end in a /.
pgo_client_cert_secret pgo.tls Sets the secret that the pgo-client will use when connecting to the PostgreSQL Operator.
pgo_client_container_install false Run the pgo-client deployment with the PostgreSQL Operator.
pgo_client_install true Enable to download the pgo client binary as part of the Ansible install
pgo_client_version 4.6.1 Required
pgo_cluster_admin false Required Determines whether or not the cluster-admin role is assigned to the PGO service account. Must be true to enable PGO namespace & role creation when installing in OpenShift.
pgo_disable_eventing false Set to configure whether or not eventing should be enabled for the Crunchy PostgreSQL Operator installation.
pgo_disable_tls false Set to configure whether or not TLS should be enabled for the Crunchy PostgreSQL Operator apiserver.
pgo_image_prefix registry.developers.crunchydata.com/crunchydata Required Configures the image prefix used when creating containers for the Crunchy PostgreSQL Operator (apiserver, operator, scheduler..etc).
pgo_image_pull_secret Name of a Secret containing credentials for container image registries.
pgo_image_pull_secret_manifest Provide a path to the Secret manifest to be installed in each namespace. (optional)
pgo_image_tag centos8-4.6.1 Required Configures the image tag used when creating containers for the Crunchy PostgreSQL Operator (apiserver, operator, scheduler..etc)
pgo_installation_name devtest Required The name of the PGO installation.
pgo_noauth_routes Configures URL routes with mTLS and HTTP BasicAuth disabled.
pgo_operator_namespace pgo Required Set to configure the namespace where Operator will be deployed.
pgo_tls_ca_store Set to add additional Certificate Authorities for Operator to trust (PEM-encoded file).
pgo_tls_no_verify false Set to configure Operator to verify TLS certificates.
reconcile_rbac true Determines whether or not the PostgreSQL Operator will granted the permissions needed to reconcile RBAC within targeted namespaces.
scheduler_timeout 3600 Required Set to a value in seconds to configure the pgo-scheduler timeout threshold when waiting for schedules to complete.
service_type ClusterIP Set to configure the type of Kubernetes service provisioned on all newly created clusters.
sync_replication false If set to true will automatically enable synchronous replication in new PostgreSQL clusters.

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:

Name Required Description
storage<ID>_name Yes Set to specify a name for the storage configuration.
storage<ID>_access_mode Yes Set to configure the access mode of the volumes created when using this storage definition.
storage<ID>_size Yes Set to configure the size of the volumes created when using this storage definition.
storage<ID>_class Required when using the dynamic storage type Set to configure the storage class name used when creating dynamic volumes.
storage<ID>_supplemental_groups Required when using NFS storage Set to configure any supplemental groups that should be added to security contexts on newly created clusters.
storage<ID>_type Yes Set to either create or dynamic to configure the operator to create persistent volumes or have them created dynamically by a storage class.

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.

Name Default Required Description
backrest_storage default Required Set the value of the storage configuration to use for the pgbackrest shared repository deployment created when a user specifies pgbackrest to be enabled on a cluster.
backup_storage default Required Set the value of the storage configuration to use for backups, including the storage for pgbackrest repo volumes.
primary_storage default Required Set to configure which storage definition to use when creating volumes used by PostgreSQL primaries on all newly created clusters.
replica_storage default Required Set to configure which storage definition to use when creating volumes used by PostgreSQL replicas on all newly created clusters.
wal_storage Set to configure which storage definition to use when creating volumes used for PostgreSQL Write-Ahead Log.

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

Name Value
storage1_name default
storage1_access_mode ReadWriteOnce
storage1_size 1G
storage1_type dynamic

Host Path Storage

Name Value
storage2_name hostpathstorage
storage2_access_mode ReadWriteMany
storage2_size 1G
storage2_type create

NFS Storage

Name Value
storage3_name nfsstorage
storage3_access_mode ReadWriteMany
storage3_size 1G
storage3_type create
storage3_supplemental_groups 65534

NFS Storage Red

Name Value
storage4_name nfsstoragered
storage4_access_mode ReadWriteMany
storage4_size 1G
storage4_match_labels crunchyzone=red
storage4_type create
storage4_supplemental_groups 65534

StorageOS

Name Value
storage5_name storageos
storage5_access_mode ReadWriteOnce
storage5_size 5Gi
storage5_type dynamic
storage5_class fast

Primary Site

Name Value
storage6_name primarysite
storage6_access_mode ReadWriteOnce
storage6_size 4G
storage6_type dynamic
storage6_class primarysite

Alternate Site

Name Value
storage7_name alternatesite
storage7_access_mode ReadWriteOnce
storage7_size 4G
storage7_type dynamic
storage7_class alternatesite

GCE

Name Value
storage8_name gce
storage8_access_mode ReadWriteOnce
storage8_size 300M
storage8_type dynamic
storage8_class standard

Rook

Name Value
storage9_name rook
storage9_access_mode ReadWriteOnce
storage9_size 1Gi
storage9_type dynamic
storage9_class rook-ceph-block

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

Name Default Required Description
pod_anti_affinity preferred This will set the default pod anti-affinity for the deployed PostgreSQL clusters.
pod_anti_affinity_pgbackrest This will set the default pod anti-affinity for the pgBackRest pods.
pod_anti_affinity_pgbouncer This will set the default pod anti-affinity for the pgBouncer pods.

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.