Labels and annotations v1
Resources in Kubernetes are organized in a flat structure, with no hierarchical information or relationship between them. However, such resources and objects can be linked together and put in relationship through labels and annotations.
- an annotation is used to assign additional non-identifying information to resources with the goal to facilitate integration with external tools
- a label is used to group objects and query them through Kubernetes' native selector capability
You can select one or more labels and/or annotations you will use in your EDB Postgres for Kubernetes deployments. Then you need to configure the operator so that when you define these labels and/or annotations in a cluster's metadata, they are automatically inherited by all resources created by it (including pods).
Label and annotation inheritance is the technique adopted by EDB Postgres for Kubernetes in lieu of alternative approaches such as pod templates.
Below is a list of predefined labels that are managed by EDB Postgres for Kubernetes.
: Backup identifier, only available on
: Name of the cluster
: Applied to a
Backup resource if the backup is the first one created from
ScheduledBackup object having
immediate set to
: Name of the PostgreSQL instance - this label replaces the old and
: Role of the job (i.e.
: Currently fixed to
instance to identify a pod running PostgreSQL
: Name of the PgBouncer pooler
: Purpose of the PVC, such as
: Available on
Secret resources. When set to
a change in the resource will be automatically reloaded by the operator.
: When available, name of the
ScheduledBackup resource that created a given
: Whether the instance running in a pod is a
primary or a
: The timeline of the instance when a backup was taken
: The year a backup was taken
: The year/month when a backup was taken
: The date in ISO 8601 format (
YYYYMMDD) of the backup
: Whether the backup is online (hot) or cold (taken when Postgres is down)
Below is a list of predefined annotations that are managed by EDB Postgres for Kubernetes.
: Name of the AppArmor profile to apply to the named container.
documentation for details
: Filter to control the coredump of Postgres processes, expressed with a
bitmask. By default it is set to
0x31 in order to exclude shared memory
segments from the dump. Please refer to "PostgreSQL core dumps"
for more information.
: Manifest of the
Cluster owning this resource (such as a PVC) - this label
replaces the old and deprecated
: List, expressed in JSON format, of the instances that need to be fenced.
The whole cluster is fenced if the list contains the
: Applied to a
Cluster resource for testing purposes only, in order to
simulate the behavior of
barman-cloud-backup prior to version 3.4 (Jan 2023)
--name option was not available.
: The hash value of the resource
: Applied to a
Cluster resource to control the declarative hibernation feature.
Allowed values are
: Pull secrets managed by the operator and automatically set in the
ServiceAccount resources for each Postgres cluster
: On a pod resource, identifies the serial number of the instance within the
: Version of the operator
: Output of the
pg_controldata command - this annotation replaces the old and
: Deprecated as the
k8s.enterprisedb.io/podSpec annotation now also contains the pod environment
: Snapshot of the
spec of the Pod generated by the operator - this annotation replaces
the old and deprecated
: Hash of the pooler resource
: Current status of the pvc, one of
: When set to
disabled on a
Cluster, the operator prevents the
reconciliation loop from running
: Contains the latest cluster
reload is triggered by user through plugin
: When set to
true on a
Cluster resource, the operator disables the check
that ensures that the WAL archive is empty before writing data. Use at your own
: The WAL at the start of a backup
: The WAL at the conclusion of a backup
: The time a backup started
: The time a backup ended
: The time a snapshot started
: The time a snapshot was marked as ready to use
: When available, the time of last requested restart of a Postgres cluster
By default, no label or annotation defined in the cluster's metadata is inherited by the associated resources. In order to enable label/annotation inheritance, you need to follow the instructions provided in the "Operator configuration" section.
Below we will continue on that example and limit it to the following:
Feel free to select the names that most suit your context for both
annotations and labels. Remember that you can also use wildcards
in naming and adopt strategies like
mycompany/* for all labels
or annotations starting with
mycompany/ to be inherited.
When defining the cluster, before any resource is deployed, you can properly set the metadata as follows:
Once the cluster is deployed, you can verify, for example, that the labels have been correctly set in the pods with:
Currently, EDB Postgres for Kubernetes does not automatically propagate labels or annotations deletions. Therefore, when an annotation or label is removed from a Cluster, which was previously propagated to the underlying pods, the operator will not automatically remove it on the associated resources.