Kubernetes: Labels, Selectors and Annotations

Claire Lee
5 min readMar 7, 2023

--

Labels, selectors, and annotations are key concepts in Kubernetes for managing objects. Labels are like tags that identify and categorize Kubernetes objects. Selectors allow users to choose a specific subset of objects based on a shared set of labels. Annotations provides additional information about an object, such as build information or release notes. In a restaurant, labels could be like the different categories of dishes on the menu, selectors could be used by waitstaff to filter specific dishes based on dietary restrictions, and annotations could be additional notes or descriptions added by the chef or kitchen staff to provide more context for preparation.

Kubernetes: Labels, Selectors and Annotations

Labels(Categories of dishes)

labels

Labels are key-value pairs attached to Kubernetes objects to categorize and organize them. They can be used to identify different objects within a cluster, based on common properties such as application name, environment, or version.

For instance, imagine you have a deployment for a web application that you have labeled with the key-value pair app=webapp. Later, you want to create a service endpoint to expose the web application. To do this, you could create a service with a selector that includes the label app=webapp. This would match any objects in the cluster with the label app=webapp, including the deployment. This way, the service will correctly route traffic to the deployment that hosts the web application.

analogy: Categories of dishes

In a restaurant, labels could be like the various categories of dishes on the menu, such as appetizers, entrees, or desserts.

Selectors(Filters to find dishes)

selectors

Selectors are used to identify or filter a set of objects based on their labels. They allow users to select a specific subset of objects based on a common set of labels. Selectors are used in various Kubernetes operations such as creating service endpoints or defining deployments.

Suppose you have a microservices-based application running on a Kubernetes cluster, pods have labels like app=backend, app=frontend, env=production to identify their functionalities. To expose the backend application to the public via a service, you create a service with the selector app=backend. This ensures only the backend functionality is accessible to users, while pods with other labels remain hidden.

analogy: Filters to find dishes

In a restaurant, selectors could be like the filters used by the waitstaff to find dishes that meet specific criteria, such as vegetarian or gluten-free.

Annotations(Additional notes about a dish)

annotations

Annotations are key/value pairs that are attached to Kubernete sobjects and can provide additional information about the object. Unlike labels, annotations are not used by selector for identifying and selecting objects. Instead, annotations are used to store arbitrary metadata, such as build information or release notes, which can be used by other systems or tools.

Suppose you have a deployment object in your Kubernetes cluster with the following annotations:

annotations:
build_version: v1.2.3
git_commit: 235f67a
release_notes: |
- Added support for feature X
- Improved performance of component Y

Here, the annotations provide additional information about the deployment, such as the build version, the Git commit ID, and the release notes for the latest update. These annotations can be accessed by other systems or tools that require this metadata, such as a continuous integration/continuous deployment (CI/CD) pipeline or a monitoring tool.

analogy: Additional notes about a dish

In a restaurant, annotations could be like additional notes or descriptions about a dish that the chef or kitchen staff attach to the order to provide more context or instructions for preparation.

Manifest File

Manifest File

labels

pod.yaml

apiVersion: v1
kind: Pod
metadata:
name: <pod_name>
namespace: <namespace_name>
labels:
<key1>: <value1>
<key2>: <value2>
:
:
<keyN>: <valueN>

spec:
containers:
- name: <container1_name>
image: <image>
- name: <container2_name>
image: <image>

selectors

replicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: <replicaSet_name>
labels:
<key1>: <value1>
<key2>: <value2>
:
:
<keyN>: <valueN>
spec:
replicas: <number_of_replicas>
selector:
matchLabels:
<key1>: <value1>
<key2>: <value2>
:
:
<keyN>: <valueN>
template:
# pod template start here
metadata:
name: <pod_name>
labels:
<key1>: <value1>
<key2>: <value2>
:
:
<keyN>: <valueN>
spec:
containers:
- name: <container1_name>
image: <image>
- name: <container2_name>
image: <image>
# pod template end here

annotations

pod.yaml

apiVersion: v1
kind: Pod
metadata:
name: <pod_name>
annotations:
<key1>: <value1>
<key2>: <value2>
:
:
<keyM>: <valueM>

labels:
<key1>: <value1>
<key2>: <value2>
:
:
<keyN>: <valueN>
spec:
containers:
- name: <container1_name>
image: <image>
- name: <container2_name>
image: <image>

Commands

labels and selectors commands
  • Create a pod with labels
$ kubectl run <pod-name> --image=<image> --labels=<key1>=<value1>,<key1>=<value1>

analogy: Creating a new dish and adding tags to it for better organization and identification

  • Retrieve a list of pods based on their labels
$ kubectl get pods --selector key1=value1,key2=value2
$ kubectl get pods -l key1=value1,key2=value2

analogy: Filter dishes based on their categories before serving them to the customers

--

--

Claire Lee
Claire Lee

Responses (1)