Operator configuration v2.0.0

Suggest edits

EDB Postgres® AI for CloudNativePG™ Global Cluster Operator configuration

The operator for EDB CloudNativePG Global Cluster (PGD4K) is installed from a standard deployment manifest and follows the convention over configuration paradigm. While this is fine in most cases, there are some scenarios where you want to change the default behavior, such as:

  • defining a different default image for PGD
  • defining an additional pull secret for operator and operand images

The behavior of the operator can be customized through a ConfigMap/Secret that is located in the same namespace of the operator deployment and with pgd-operator-controller-manager-config as the name.

Important

Any change to the config's ConfigMap/Secret will not be automatically detected by the operator, and as such, it needs to be reloaded (see below). Moreover, changes only apply to the resources created after the configuration is reloaded.

Important

The operator first processes the ConfigMap values and then the Secret’s, in this order. As a result, if a parameter is defined in both places, the one in the Secret will be used.

Available options

The operator looks for the following environment variables to be defined in the ConfigMap/Secret:

NameDescription
PGD_IMAGE_NAMEPGD operand image name to overwrite the default one in manifest.
PULL_SECRET_NAMEName of an additional pull secret to be defined in the operator's namespace and to be used to download images
BOOTSTRAP_JOB_IMAGE_NAMEBootstrap job image name is the image name to overwrite the default bootstrap job image if barman-cloud plugin is used (k8s.pgd.enterprisedb.io/bootstrapJobImage annotation still takes precedence, if present in PGDGroup)
WEBHOOK_CERT_DIRWebhook cert dir is the directory where the certificates for the webhooks need to be written. This is different between plain Kubernetes and OpenShift
OPERATOR_IMAGE_NAMEOperator image name is the name of the image of the operator, that is used to bootstrap Pods
POSTGRES_TIMEOUTPostgres timeout contains the timeout in seconds used when communicating with a Postgres instance (Defaults to 15)
MAX_CONCURRENT_RECONCILESMax concurrent reconciles is the maximum number of concurrent Reconciles which can be run (Defaults to 15)
MONITORING_QUERIES_CONFIGMAPName of the ConfigMap in the operator namespace containing default monitoring queries to distribute to all PGDGroup namespaces (see Default Monitoring Queries)
MONITORING_QUERIES_SECRETName of the Secret in the operator namespace containing default monitoring queries to distribute to all PGDGroup namespaces (see Default Monitoring Queries)

When you specify an additional pull secret name using the PULL_SECRET_NAME parameter, the operator will use that secret to create a pull secret for every created PGD group. That secret will be named <group-name>-pull.

The namespace where the operator looks for the PULL_SECRET_NAME secret is where you installed the operator. If the operator is not able to find that secret, it will ignore the configuration parameter.

Defining an operator config map

The example below customizes the behavior of the operator, by defining an additional image pull secret.

apiVersion: v1
kind: ConfigMap
metadata:
  name: pgd-operator-controller-manager-config
  namespace: pgd-operator-system
data:
  PULL_SECRET_NAME: additional-pull-secret

Defining an operator secret

The example below customizes the behavior of the operator, by defining the default operand image names.

apiVersion: v1
kind: Secret
metadata:
  name: pgd-operator-controller-manager-config
  namespace: pgd-operator-system
type: Opaque
stringData:
  PGD_IMAGE_NAME: docker.enterprisedb.com/k8s/postgresql-pgd:17.6-pgd612-expanded-ubi

Restarting the operator to reload configs

For the change to be effective, you need to recreate the operator pods to reload the config map. If you have installed the operator on Kubernetes using the manifest you can do that by issuing:

kubectl rollout restart deployment \
    -n pgd-operator-system \
    pgd-operator-controller-manager

Otherwise, If you have installed the operator using OLM, or you are running on Openshift, run the following command specifying the namespace the operator is installed in:

kubectl delete pods -n [NAMESPACE_NAME_HERE] \
  -l app.kubernetes.io/name=pgd-operator
Warning

Customizations will be applied only to PGD groups resources created after the reload of the operator deployment.

pprof HTTP Server

The operator can expose a PPROF HTTP server with the following endpoints on localhost:6060:

  • /debug/pprof/. Responds to a request for "/debug/pprof/" with an HTML page listing the available profiles
  • /debug/pprof/cmdline. Responds with the running program's command line, with arguments separated by NULL bytes.
  • /debug/pprof/profile. Responds with the pprof-formatted cpu profile. Profiling lasts for duration specified in seconds GET parameter, or for 30 seconds if not specified.
  • /debug/pprof/symbol. Looks up the program counters listed in the request, responding with a table mapping program counters to function names.
  • /debug/pprof/trace. Responds with the execution trace in binary form. Tracing lasts for duration specified in seconds GET parameter, or for 1 second if not specified.

To enable the pprof server, you need to edit the operator deployment to add the flag --pprof-server=true.

You can do this by executing these commands:

kubectl edit deployment -n pgd-operator-system pgd-operator-controller-manager

Then on the edit page scroll down the container args and add --pprof-server=true, as in this example:

      containers:
      - args:
        - controller
        - --enable-leader-election
        - --config-map-name=pgd-operator-controller-manager-config
        - --secret-name=pgd-operator-controller-manager-config
        - --log-level=info
        - --pprof-server=true # relevant line
        command:
        - /manager

Save the changes; the deployment now will execute a roll-out, and the new pod will have the PPROF server enabled.

PG4K Operator configuration

The EDB CloudNativePG Global Cluster (PGD4K) operator manages each PGD node using the Cluster resource defined by the PG4K operator. Therefore, the configuration for the PG4K operator remains applicable. If you need to modify the default behavior of the PG4K operator, like changing the default monitor query, you can do so by defining a Configmap or Secrets within the PG4K operator's namespace.

For reference, there are available options supported by PG4K operator's Configmap or Secrets.

You can follow the steps defined operator configuration for more details.

↑ Up

EDB Postgres® AI for CloudNativePG™ Global Cluster

Next →

Examples of configuration