To support multi-dimensional metadata management, Kubernetes offers labels and annotations. They both attach metadata to resources in the format of key-value pairs, but their purposes and use cases differ significantly.
Both labels and annotations apply to various Kubernetes resource types. This section will specifically examine their use in pods.
Pod labels enable intelligent resource association. Once labels are added to pods, other Kubernetes resources can accurately identify and be associated with these pods using label selectors. Label keys and values must follow specific naming rules. For details, see Syntax and character set. For example, you can add the following label to two workloads (App 1 and App 2), respectively:
When creating workload App 3, configure a scheduling policy as follows: Set Workload Affinity to Customize affinity, and add a Required policy under Workload Affinity. Set Namespace to App 1's namespace, Topology Domain to kubernetes.io/hostname, Label Key to release, Operator to In (default), and Label Value to alpha. Kubernetes will attempt to schedule the workload to the node running App 1, or to another node meeting these conditions. This ensures App 1 and App 3 are co-located when possible. For details, see Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
You can add labels to a pod using either the console or YAML.
When creating or upgrading a workload on the CCE console, you can add a pod label by clicking Labels and Annotations in the Advanced Settings area. This label helps identify the pod within the cluster. When you create a workload, CCE automatically adds app=workload-name and version=v1 labels to the pod by default.
When creating or upgrading a workload, you can add a pod label in the following area of the YAML file:
...spec:selector:matchLabels:app: nginxversion: v1template:metadata:labels:app: nginxversion: v1spec:...
CCE provides some advanced functions for pods. These functions can be implemented by adding annotations to the YAML files. You can add annotations to a pod using either the console or YAML.
When creating or upgrading a workload on the CCE console, you can add a pod annotation by clicking Labels and Annotations in the Advanced Settings area to enable advanced functions for the pod.
For example, to disable the collection of container standard output logs for a pod, set the pod annotation to kubernetes.AOM.log.stdout='[]' and click Confirm.
When creating or upgrading a workload using YAML, you can use the annotations parameter to enable advanced pod functions.
For example, you can use annotations to disable the collection of container standard output logs for a pod:
...spec:replicas: 1 # Number of podsselector:matchLabels: # Selector for selecting resources with specific labelsapp: nginxtemplate:metadata:labels: # Labelsapp: nginxannotations:kubernetes.AOM.log.stdout: '[]'...
Table 1 provides some typically used annotations. You can add annotations for pods as required.
Annotation | Description | Default Value |
|---|---|---|
kubernetes.AOM.log.stdout | The standard output log collection setting for containers. If left unspecified, the standard output logs from all containers will be automatically reported to AOM by default. You can customize this annotation to collect standard output logs only from specified containers or disable standard output log collection for all containers. Example:
| N/A |
metrics.alpha.kubernetes.io/custom-endpoints | The AOM metric reporting setting, which allows specified metrics to be sent to AOM. For details, see Monitoring Custom Metrics on AOM. | N/A |
prometheus.io/scrape | The Prometheus metric reporting setting, which allows specified metrics to be sent to Prometheus. If set to true, the metrics of the specified workload will be reported to Prometheus. | N/A |
prometheus.io/path | URL for Prometheus to collect data. | /metrics |
prometheus.io/port | Endpoint port number for Prometheus to collect data. | N/A |
prometheus.io/scheme | Protocol used by Prometheus to collect data. The value can be http or https. | N/A |
kubernetes.io/ingress-bandwidth | The ingress bandwidth of a pod. It controls the rate at which the pod receives data to ensure that the pod can process external requests. For details, see Configuring QoS for a Pod. | N/A |
kubernetes.io/egress-bandwidth | The egress bandwidth of a pod. It controls the rate at which the pod sends data to external systems. This affects the efficiency of communication between the pod and external services or users. For details, see Configuring QoS for a Pod. | N/A |