Kubernetes: Labels, Selectors and Annotations
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.
Labels(Categories of dishes)
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 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 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
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
- 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
These are my personal notes for CKA exam preparation on Kubernetes. Please feel free to correct me if you notice any errors. 😊
Related Story
Reference: