K8s Labels & Selectors

In this post, we will look at

• What Kubernetes(K8s) Labels and Selectors are
• Why do we need them
• How to use them

Let’s try to understand the concept with an analogy. If you ever have looked at different types of homes, one can see townhomes, condos, Single Family Homes, apartments, etc.

Apartment vs Condo vs Single Family Home vs Townhomes

Let’s say we would like to categorize these homes by

- Size(sqft area)
- Type(condo, apartment, sfh, townhome)
- Number of people(2,4,6,8+)

These are nothing but Labels. Selectors help filter out things like gives all homes which are of type SFH and greater than 500sqft in size. One can mix and match different types of selectors.

Overtime in K8s one can have 1000s of different objects and one would need ways to label & select certain types of objects. Labels are key/value pairs that are attached to objects, such as pods.

Example labels:

• “release” : “stable”, “release” : “canary”
• “environment” : “dev”, “environment” : “qa”, “environment” : “production”
• “tier”: “frontend”, “tier”: “backend”, “tier”: “cache”
• “partition” : “customerA”, “partition” : “customerB”
• “track”: “daily”, “track”: “weekly”

Why do we need these labels & selectors?

Even a small Kubernetes cluster may have hundreds of Containers, Pods, Services, and many other Kubernetes API objects.

It quickly becomes annoying to page through pages of kubectl output to find your object, labels address this issue perfectly.

The primary reasons you should use labels are:

• enables you to logically organize all your Kubernetes workloads in all your clusters,
• enables you to very selectively filter kubectl outputs to just the objects you need.
• enables you to understand the layers and hierarchies of all your API objects.

How do we use the same?

Let’s see we would like to create a Pod with a label. Using minikube for examples below, you could try this on any other K8 cluster.

environment=production

There are two ways we could do the same using the imperative way or the declarative way

kubectl run nginx-imperative --image=nginx --restart=Never -l environment=production

Let’s try to confirm the POD using the label

kubectl get pods -l environment=production
NAME               READY   STATUS    RESTARTS   AGE
nginx-imperative   1/1     Running   0          13s

Let’s try using the declarative way

# declarative.yml
apiVersion: v1
kind: Pod
metadata:
  name: declarative-nginx
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx

Let’s apply the YAML file, we see the POD with the given label is created. With -l the option here, we are selecting a specific label

kubectl apply -f declarative.yml
pod/declarative-nginx created
kubectl get pods -l environment=production
NAME                READY   STATUS    RESTARTS   AGE
declarative-nginx   1/1     Running   0          74s
nginx-imperative    1/1     Running   0          2m43s
kubectl get pods -l environment=production --no-headers
declarative-nginx   1/1   Running   0     2m8s
nginx-imperative    1/1   Running   0     3m37s

Can we use multiple selectors?

Of course, the example below uses selectors env, bu & type

kubectl get pods -l env=prod,bu=finance,type=app1 --no-headers
kubectl get pods -l 'environment in (production, qa)'

How to see all labels being used?

kubectl get all --show-labels
kubectl get pod --show-labels

K8 documentation for labels & selectors has a lot more details if you would like to explore. As a followup to this, we have a post describing the differences between labels & annotations here. That's all for now, till next time ciao!