Percona Operator for PostgreSQL - Labels and annotations (original) (raw)

Labels and annotations are used to attach additional metadata information to Kubernetes resources.

Labels and annotations are rather similar. The difference between them is that labels are used by Kubernetes to identify and select objects, while annotations are assigning additional non-identifying information to resources. Therefore, typical role of Annotations is facilitating integration with some external tools.

Setting labels and annotations in the Custom Resource

You can set labels and/or annotations as key/value string pairs in the Custom Resource metadata section of the deploy/cr.yaml. For PostgreSQL, pgBouncer and pgBackRest Pods, use instances.metadata.annotations/instances.metadata.labels,proxy.pgbouncer.metadata.annotations/proxy.pgbouncer.metadata.labels, orbackups.pgbackrest.metadata.annotations/backups.pgbackrest.metadata.labelskeys as follows:

`apiVersion: pgv2.percona.com/v2 kind: PerconaPGCluster ... spec: ... instances:

For PostgreSQL and pgBouncer Services, use expose.annotations/expose.labels orproxy.pgbouncer.expose.annotations/proxy.pgbouncer.expose.labels keys as follows:

apiVersion: pgv2.percona.com/v2 kind: PerconaPGCluster ... spec: ... expose: annotations: my-annotation: value1 labels: my-label: value2 ...

You can also use the top-level spec metadata.annotations and metadata.labelsoptions to set annotations and labels at a global level, for all resources created by the Operator:

apiVersion: pgv2.percona.com/v2 kind: PerconaPGCluster ... spec: ... metadata: annotations: my-global-annotation: value1 labels: my-global-label: value2 ...

The easiest way to check which labels are attached to a specific object with is using the additional --show-labels option of the kubectl get command. Checking the annotations is not much more difficult: it can be done as in the following example:

$ kubectl get service cluster1-pgbouncer -o jsonpath='{.metadata.annotations}'

Settings labels and annotations to the Operator Pod

You can assign labels and/or annotations to the Pod of the Operator itself by editing the deploy/operator.yaml configuration file before applying it during the installation.

apiVersion: apps/v1 kind: Deployment ... spec: ... template: metadata: labels: app.kubernetes.io/component: operator app.kubernetes.io/instance: percona-postgresql-operator app.kubernetes.io/name: percona-postgresql-operator app.kubernetes.io/part-of: percona-postgresql-operator pgv2.percona.com/control-plane: postgres-operator ...

Special annotations

Metadata can be used as an additional way to influence the Operator behavior by setting special annotations.

Customizing Patroni version

Starting from the Operator 2.6.0, Percona distribution for PostgreSQL comes with Patroni 4.x, which introduces breaking changes compared to previously used 3.x versions. To maintain backward compatibility, the Operator needs to detect the Patroni version used in the image. For this, it runs a temporary Pod named cluster_name-patroni-version-check with the following default resources:

Resources: Requests: memory: 32Mi cpu: 50m Limits: memory: 64Mi cpu: 100m

User can disable this auto-detection feature by manually setting the Patroni version via the following annotation in the metadata part of the Custom Resource (it should contain “4” for Patroni 4.x or “3” for Patroni 3.x):

apiVersion: pgv2.percona.com/v2 kind: PerconaPGCluster metadata: name: cluster1 annotations: pgv2.percona.com/custom-patroni-version: "4" ...


Last update: 2025-04-07