Operator configuration v1
EDB Postgres Distributed for Kubernetes Operator configuration
The operator for EDB Postgres Distributed for Kubernetes (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 or PGD proxy
- 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
:
Name | Description |
---|---|
PGD_IMAGE_NAME | PGD operand image name to overwrite the default one in manifest. |
PGD_PROXY_IMAGE_NAME | PGD proxy operand image name to overwrite the default one in manifest. |
PULL_SECRET_NAME | Name of an additional pull secret to be defined in the operator's namespace and to be used to download images |
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.
Defining an operator secret
The example below customizes the behavior of the operator, by defining the customized operand image names.
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:
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:
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 operator you need to edit the operator deployment add the flag --pprof-server=true
.
You can do this by executing these commands:
Then on the edit page scroll down the container args and add
--pprof-server=true
, as in this example:
Save the changes; the deployment now will execute a roll-out, and the new pod will have the PPROF server enabled.
EDB Postgres for Kubernetes Operator configuration
The EDB Postgres Distributed for Kubernetes (PGD4K) operator manages each PGD node using the Cluster
resource defined by the EDB Postgres for Kubernetes (PG4K) operator. Therefore, the configuration for the PG4K
operator remains applicable. Please refer to the operator configuration
for more details.