A Deep Dive into Kubernetes Resource Classification and Configuration

Overview

Kubernetes, a container orchestrator, is designed to handle applications at scale. While working with multiple objects we may need to group them. Metadata like, labels, selectors and annotations play an important role while configuring and working with kubernetes objects.

Labels and selectors are used to select a group of objects, and annotations attach additional information about resources. Experiment with our hands-on lab to dig deep into the basic concepts of Kubernetes.

What are Labels?

• Labels are key-value pairs.
• Labels can be attached to an object at creation time or at run time.
• Key-name can be written as prefix and name where prefix is optional.
• Labels key must be unique for a particular object.
• Labels are used to filter a group of objects.
• Labels do not provide uniqueness as many objects may have the same key- value pair.

Syntax for Labels

Label Key:

• Prefix and name separated by /
• Up to 253 characters allowed as a prefix which is a DNS subdomain.
• Up to 63 alphanumeric characters as names which allowed dash -, underscore _, and dot . in between.
• If a prefix is not present in a keyname it is taken as a private for the user.

Label Value:

•  Allows 0 to 63 alphanumeric characters.
• Supports special characters  dash -, underscore _, and dot . in between.

How to Add Labels?

Different ways to attach labels with objects,

1) Add labels in yaml configuration before creating objects.

Metadata field has labels to select as a target object for other resources.

# my-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    tier: frontend
    release: stable  
    env: production
spec:
  containers:
    - name: my-cont
      image: nginx

• To create a pod using my-pod.yaml

kubectl apply -f my-pod.yaml 

• To list the pods with labels

kubectl get pods --show-labels 

2) Add labels at runtime.

• To add Label to the object(pod) that is already created

kubectl label pod/<pod_name> <key_name>=<key_value>

kubectl label pod my-pod app=nginx

• To remove Label from the object(pod)

kubectl label pod/<pod_name> <key_name>-

kubectl label pod my-pod app-

Note: This change will not reflect in a configuration yaml manifest directly.

3) Add labels using the edit command.

• To add/remove labels using edit command

kubectl edit pod/<pod_name>

After editing and updating labels,  save and exit to reflect the changes.

• To check the labels are assigned to the object

kubectl get <object-name> --show-labels

kubectl get pods --show-labels

What are Selectors?

Selectors are used to select a set of objects tagged with a particular label.

There are two types of label selectors :

• Equality based
• Set based

Equality-based Selector

It specifies the exact key-value to match. Three types of equality based operators are used. In selection, =, == stands for equality and != stands for inequality. Multiple values with a single key are not allowed with an equality based selector.

For Example,

• To create and run pods with labels 

kubectl run my-pod0 --image=nginx -l tier=front-end

kubectl run my-pod1 --image=nginx:1.23.4 -l tier=front-end,env=dev

kubectl run my-pod2 --image=nginx:stable -l tier=back-end,env=test

kubectl run my-pod3 --image=nginx:alpine -l tier=back-end,env=prod

• To list the pods with labels

kubectl get pods --show-labels

• To filter the objects with equality based selectors(!=)

kubectl get pods -l tier!=back-end

• To list an object using selector (=)

kubectl get pods --selector tier=back-end,env=test

Set-based Selector

It may specify multiple values with a single key and any one of the key-values should match to select that object.

If multiple selectors are in the manifest file, all the selectors have to match to select the object (like, AND operator).

For Example,

Use the pods created in previous section,

• To select set based selector (in)

kubectl get pods -l 'env in (dev,prod)'

• To select an object with selector option (notin)

kubectl get pods --selector 'tier notin (front-end)'

• To select an object with label key (exist)

kubectl get pods -l 'env'

Where To Specify Selector?

Specification field of replicaset/deployment/service has a matchLabels field in the selector.

spec:
  selector:
    matchLabels:
      app: nginx

Using the selector field the object targets another group of objects by the same label of the selected object.

What are annotations?

Annotations are used to specify non-identifying information to objects. Annotations attached in the metadata section with key-value pairs like labels. The syntax is similar to the label.

Some example of annotations:

• Contact details of responsible person in deployment metadata
• Details of on-call persons
• Build, release, or image information

It is not used to filter, group, or operate on resources. It is useful to get additional information about resources.

• Use the following yaml manifest to create a pod with annotations. (file is added in the lab set up)

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    tier: front-end
  annotations:
    on-call: dev-team-member
    tel: "5467998973"
spec:
  containers:
  - name: my-cont
    image: nginx

• To create a pod with 

kubectl apply -f pod.yaml

• To view attached annotations

kubectl describe pod my-pod

Use-Cases of Labels and Selectors with Examples

Some of the Use-Cases that we will discuss in detail.

1. Filter the set of objects
2. Allow operations on multiple objects
3. ReplicaSet controls number of pods using labels
4. Deployment/ReplicaSet targets pod using labels
5. Services target deployment using labels
6. Other Use-Cases

Filter the set of objects

One of the use cases of labels is to select a group of objects. In the selector section above, we already covered that.

Allow Operations on Multiple objects

To perform the same operations on multiple objects we need to select objects by their labels.

• Bulk operations like

kubectl delete <obj-1>,<obj-2> -l key in (value-1,value-2)

For Example,

• To delete all pods having a key of label tier from the selector section.

kubectl delete pod -l tier

ReplicaSet controls Number of Pods using Labels

If we create, a pod with a label and the same label is specified in the ReplicaSet manifest file in the same namespace. The replica set controller will consider the pod as a part of its replicas.

Let’s understand, with an example, how Replicaset controls the number of pods running using labels.

• To create and run a pod with labels

kubectl run my-pod --image=nginx:stable -l env=dev

Following replicaset-def.yaml manifest for creating replicaset is attached with lab environment.

# replicaset-def.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-rs
  labels:
    tier: front-end
    app: myapp
spec:
  replicas: 3
  template:
    metadata:
      name: mypod
      labels:
        env: dev
    spec:
      containers:
      - name: my-nginx
        image: nginx:latest
  selector:
    matchLabels:
      env: dev

Note: matchLabel env=dev in the selector field is used to choose the pod specified in a pod template label.

• To create a ReplicaSet

kubectl create -f replicaset-def.yaml

• To list the pods

kubectl get pods

Due to the same labels ReplicaSet directly controls the number of replicas that is 3 in the yaml file and creates 2 pods from the yaml manifest as one with the same label already exists.

Note: The same is applicable for Deployment as well.

• To delete all pods and ReplicaSet created in this section

kubectl delete rs my-rs

Deployment/ReplicaSet Targets pod Using Labels

With the selector field in the spec section of Deployment/ReplicaSet, the pods will be part of deployment if the labels in the pod’s template match with that of the selector’s field.

• A deploy-def.yaml configuration file for deloyment is included in lab setup.

# deploy-def.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    env: prod
spec:
  replicas: 3
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
  selector:
    matchLabels:
      tier: frontend

kubectl create -f deploy-def.yaml

• To check the label of target pod from the deployment

kubectl get deploy

kubectl get pods --show-labels

• To get the details and check the label of the selected pod

kubectl describe pod <pod-name>

Check the label field of the pod which will be the same as the selector field of deployment.

Note: The same is applicable for ReplicaSet as well.

Services Target Deployment Using Labels

Likewise the previous section, Another important resource service targets deployments by labels. Let us try to understand with following example,

Use the deployment created in the previous section, if it is not deleted. If it is removed, create it using the deploy-def.yaml file mentioned above.

• Service defination is attached with lab environment.

# svc-def.yaml
apiVersion: v1
kind: Service
metadata:
  name: mysvc
  labels:
    env: prod
spec:
  ports:
  - port: 80
  selector:
    tier: frontend

Note: selector field of the service must be the same as the pod template label of the deployment configuration file. Do not use the label of deployment metadata field.

• To create a service

kubectl create -f svc-def.yaml

• To list the service

kubectl get svc

Once you run this command, you will get an IP Address under CLUSTER-IP for the above-created service.

Now check if the nginx pod created is reachable via the IP Address <ip> received from above command

curl <ip>

See the homepage of nginx in html format !!!! ALL GOOD!!!

• To get the endpoints

kubectl get ep

Notice the number of endpoints, it is 3 in this case. These endpoints are the deployment pod’s ip.

kubectl get pods -o wide

It is always a good practice to clean up the resources which have been created.

• To delete the deployments

kubectl delete deploy,svc -l 'env=prod'

Other Use Cases

• Bind Persistent Volume claim by Label.
• Troubleshoot the issues fast with the application development pipeline.
• Specify node selection criteria in a pod.
• Labels are used by other resources such as Job, DaemonSet etc.
• Release management
• To define network policies

Conclusion

Labels and selectors play a key role in Kubernetes resource selection and grouping; it controls the number of applications running per the configuration and helps other objects to target them. I hope this blog helped you understand labels and selectors in detail. I’d love to hear comments from more people for betterment.