Labels and annotations
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 Cloud Native PostgreSQL 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 Cloud Native PostgreSQL in lieu of alternative approaches such as pod templates.
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.
Defining cluster's metadata
When defining the cluster, before any resource is deployed, you can properly set the metadata as follows:
apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-example annotations: categories: database labels: environment: production workload: database app: sso spec: # ... <snip>
Once the cluster is deployed, you can verify, for example, that the labels have been correctly set in the pods with:
kubectl get pods --show-labels
Cloud Native PostgreSQL does not currently support synchronization of labels or annotations after a resource has been created. For example, suppose you deploy a cluster. When you add a new annotation to be inherited and define it in the existing cluster, the operator will not automatically set it on the associated resources.