Kubernetes Labels, Selectors, and Annotations

The use of metadata tags attached to various resources and objects is a requirement for any Kubernetes environment. It can help DevOps teams to solve several problems. DevOps teams can more quickly troubleshoot issues along the application development pipeline, apply configuration changes in bulk, and solve cost monitoring, allocation, and management challenges by correctly using Kubernetes labels.

In this article lets have a look at examples of various types of metadata and understand how to work with them.

Labels

Labels are key/value pairs attached to objects like pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not imply semantics to the core system directly. Labels are useful for organizing and selecting subsets of objects. They can be attached to objects at the time of creation and then added and modified at any time. A set of key/value labels can be defined for each object. Each Key must be distinct for each object.

Labels can be added to your resources in a variety of ways. The first and most common method is to include them directly in your configuration files and have them set when the resource is created or updated. To do this, you can specify label values at metadata. labels like so:

apiVersion: v1
kind: Pod
metadata:
  name: metadata-dev
  labels:
    environment: dev
    app: nginx

The kubectl CLI tool is another way to work with labels. To add a label to an existing resource, you can use the following command:

kubectl label pod/metadata-dev group=main

This will create a label “group” with a value of “main”

You can also remove the label using this command:

kubectl label pod/metadata-demo group-

This will remove the “group” label from the resource.

Selectors

Unlike names and UIDs, Labels do not provide uniqueness. In general, we anticipate that many objects will carry the same label (s).

Label selectors, as the name implies, allow you to identify objects that have been labelled with specific labels. In Kubernetes, the label selector is the fundamental grouping primitive.

Label selectors can either be equality-based or set-based

1. Equality-based selectors

Equality-based selectors work by specifying an exact value to match against. If you provide multiple selectors, all of them must be satisfied for the match to be considered. Three kinds of operators are admitted =, ==, !=. The first two represent equality (and are synonyms), while the latter represents inequality. For example:

environment = production
tier != frontend 

The former chooses all resources with a key of environment and a value of production. The latter selects all resources with the key tier and a value different from frontend, as well as all resources with no labels and the tier key.

2. Set-based requirement

Set-based selectors function similarly, except that you can specify multiple values in a single selector, and only one of them must match for the object to qualify.

Three kinds of operators are supported: in, notin and exists (only the key identifier). For example:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

- The first example selects all resources with key equal to environment and value equal to production or qa.

- The second example selects all resources with key equal to tier and values other than frontend and backend, and all resources with no labels with the tier key.

- The third example selects all resources including a label with key partition; no values are checked.

- The fourth example selects all resources without a label with key partition; no values are checked.

Set-based requirements can be mixed with equality-based requirements. For example:

partition in (customerA, customerB),environment!=qa 

Selectors are useful for a variety of purposes. The most typical example is probably grouping the appropriate resources for something like a service.

Annotations

Another type of metadata that can be used in Kubernetes is annotations. Annotations, unlike labels, cannot be used to identify and select objects. Their objective is to store arbitrary, non-identifying information about objects.

Because annotations are less restricted than labels, you can store special characters that labels do not allow, as well as large, structured values if your use case requires it. Labels and annotations are both key/value maps:

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Valid annotation keys consist of two segments: an optional prefix and name, separated by a slash (/). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumeric between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (.), not longer than 253 characters in total, followed by a slash (/). The kubernetes.io/ and k8s.io/ prefixes are reserved for Kubernetes core components.

For example, here's the configuration file for a Pod that has the annotation

imageregistry: https://hub.docker.com/ :

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Metadata is critical for managing larger deployments and keeping everything organized because it allows you to impose your own organizational model on Kubernetes resources in a loosely coupled manner without directly implying semantics. Metadata also gives Kubernetes a way to group, organize, and associate resources, allowing for larger and more complex structures to exist than would otherwise be feasible.

That's all for now.

Thank you for reading!

*** Explore | Share | Grow ***