Kubernetes (K8s) labels are key-value pairs that can be a powerful resource for managing, configuring, and troubleshooting. Users can use Kubernetes labels to add meaningful metadata to any Kubernetes object or resource. Because of their extensibility, a sound understanding of Kubernetes labels can make you a better K8s administrator and improve your container workflows.
In this article, we take a closer look at labels and the selectors used to filter them and work through example commands and use cases so you can get hands-on experience with K8s labels.
K8s selectors allow users to filter objects based on labels, and can be used by the Kubernetes platform as well. From a user perspective, K8s labels and selectors can manipulate objects such as:
While you can use K8s without labels, the metadata they provide is valuable to humans working with the platform. Users often need Kubernetes labels to identify K8s objects and perform useful operations on them.
For example, consider a set of pods like the example below running on the Kubernetes cluster.
Let’s assume we need to delete all the pods that belong to the dev environment. Without assigning labels, there’s no easy way to tell which pods fit that description. As a result, it can become difficult and time-consuming to find each pod and delete it.
Now, let’s suppose we assign a label to each pod based on the environment it belongs to. Here the environment is either dev or prod for example.
Now, using the label with key-value pair env: dev we can use the K8s selector with the kubectl delete command to quickly delete all the pods that belong to the dev environment.
In addition to pod deletion, we could perform many other operations on those pods. For example, we can list pods, list pods and namespaces together, or direct traffic to a list of pods or service or endpoints.
When working with Kubernetes labels, there are restrictions concerning the length and allowed values. Specifically, a valid label value:
For example, the following pod manifest has two valid labels, environment: production and app: nginx
K8s labels can be defined when a new object is created or attached to existing objects and modified later. A user can edit the object YAML definition manually or use kubectl to create/update labels.
Let’s create a pod with the label env=develop
After pod creation, we can see the label using the get subcommand. The Kubernetes labels are displayed as an additional column in the output:
Next, we can use the label subcommand to add another label to the pod.
Now, we can use the --overwrite flag to change the value for the existing label key.
Next, check if the new label is attached using the get command, the output will show the new label in addition to the existing ones.
To list the pods with label key “owner” and value “ahmad”, we will use the --selector option.
Next, use the short option -l to select the pod with label env=develop.
Kubernetes also supports set-based selectors. To demonstrate this, let’s create another pod with env=prod and owner=ijaz
We can now list the pods where the environment is either develop or prod by using the set-based selector. For example:
Other actions also support label selection. For example, we can delete both the pods using this command:
Kubernetes labels are not only for pods. You can apply them to all sorts of objects, including nodes, services, and deployments.
Now that we’ve covered the basics of working with K8s labels, let’s take a look at some common use cases.
The most common use case for labels is using label selectors in Kubernetes services and deployment objects. A service object targets pods based on label selectors.
For example, consider this service definition:
The above specification will create a new service object named "app-service", targeting TCP port 9370 on any pod with the app=MyApp label.
Similarly, using Kubernetes labels and label selectors in deployment objects enables the deployment to find the pods to be managed under the deployment.
Consider the following deployment spec:
The .spec.selector field defines how the deployment should find which Pods to manage. In this case, you select a label defined in the Pod template (app: nginx).
Using labels and selectors is also common in advanced Kubernetes scheduling. Examples of advanced K8s scheduling include node selector and pod affinity.
If you need to place a pod on a specific node, you can label the node and then use the label in your pod deployment manifest. For example, you can use this command to label a node with SSD storage.
Then, in the deployment specification, you can use the label disktype=ssd as node selector to place the pod on the node with label disktype=ssd.
While Kubernetes labels are customizable, it is best practice to use certain standard labels. For example, from the K8s docs, recommended labels include:
|name||The name of the application||Nginx|
|instance||A unique name identifying the instance of an application||frontend-blue|
|version||The current version of the application||1.0.0|
|component||The component within the architecture||Database|
Some other common labels are:
|environment||The environment in reference to the systems development lifecycle||staging|
|owner||The team or individual responsible for deploying or maintaining the application component||“Ijaz Khan”|
|managed-by||The tool being used to manage the operation of an application||helm|
|business-unit||The business unit that owns this application||“finance”|
Using Labels and Selectors in Kubernetes are not only useful constructs required in many operations, but also, are part of Kubernetes best practices, they make the operations on Kubernetes objects simple and easier. Labels are also used internally by Kubernetes for the same purpose. Users need to follow the best practices of using label names that are relevant to the application stack and environment as described in this article.
Follow our LinkedIn monthly digest to receive more free educational content like this.Follow LinkedIn K8s digest