Previously we created Pods using the following config

apiVersion: "v1"
kind: Pod
metadata:
  name: ubuntu-pod
  labels:
    app: ubuntu-pod
    version: v5
    role: backend
spec:
  containers:
  - name: ubuntu-container
    image: ubuntu
    command: ["/bin/bash"]
    args: ["-c", "while [ \"a\" = \"a\" ]; do echo \"Hi\"; sleep 5; done" ]

Lets talk about the Labels section. The main use of labels is for selection.

OS migration case

The Tech Lead in your team has decided that ubuntu is no good, we need to move to centos. So you diligently create a new pod definition as follows.

apiVersion: "v1"
kind: Pod
metadata:
  name: centos-pod
  labels:
    app: ubuntu-pod
    version: v5
    role: backend
spec:
  containers:
  - name: centos-container
    image: centos
    command: ["/bin/bash"]
    args: ["-c", "while [ \"a\" = \"a\" ]; do echo \"Hi\"; sleep 5; done" ]

Note here that the app label has remained the same because it is ultimately the same app. This is an example of bad naming of the label. A name such as hi-application would have been much better to identify the application. Remember that to create the new pod, we have to name it differently, so we *have* to change that.

$ kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
centos-pod   1/1     Running   0          34s
ubuntu-pod   1/1     Running   0          42s

Both running Yaay!

You also have a new service created by some other team in your company. As you didn’t write it, its obviously junk! Its pod definition is below.

apiVersion: "v1"
kind: Pod
metadata:
  name: junk-pod
  labels:
    app: junk-pod
    version: v5
    role: backend
spec:
  containers:
  - name: centos-container
    image: centos
    command: ["/bin/bash"]
    args: ["-c", "while [ \"a\" = \"a\" ]; do echo \"Junk\"; sleep 5; done" ]

$ kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
centos-pod   1/1     Running   0          3m48s
junk-pod     1/1     Running   0          6s
ubuntu-pod   1/1     Running   0          3m56s

So all 3 running!

How do you list all the pods that belong to your application ?

Labels come to your rescue here!

$ kubectl get pods -l "app=ubuntu-pod"
NAME         READY   STATUS    RESTARTS   AGE
centos-pod   1/1     Running   0          9m1s
ubuntu-pod   1/1     Running   0          9m9s

voila!

Filter queries

The query string following -l in the above “get pods” command has a number of variations

AND

app=bla,os=centos

This will match resources who match both criteria. Kind of like AND operator. You can use != as well.

OR

app in (junk-app, ubuntu-app)

if app is junk-app or app is ubuntu-app.

notin is the opposite of in.

app notin (junk-app, ubuntu-app)

if app is not junk-app nor ubuntu-app.

Why organize at all ?

In a small organization where there are only a few pods running and you are not too worried about “ownership” because everything belongs to everyone (noone?) you may be ok without thinking of labels etc.

Once the organization grows to some size, but not large enough to think of multiple clusters, you need to start thinking on the lines of team ownership atleast. So a label “team” is definitely in order. This will help delineate ownership of pods along team boundaries. So if one pod is found faulty, you can immediately point it to the right team for managing.

Certain Resources as you will see later need labels to choose the resources to work one.

It pays to think up front about organization because every successful business grows and that means you will start to have more microservices quickly, if you cant think of the system as an organization of a reasonable number of blocks, then how will you manage it? It will soon be impossible to have every service in your head to reason about.

Organization fail case study

In one of the companies I worked for, the number of services had grown exponentially. Also, as the model had always been that any person could raise a PR on any service, people didn’t really know which service talked to which service, or more fundamentally How many services were there! As a result, when it was decided to create copies of the production environment to handle new countries, it took 1 year to setup the new environment.

Learnings

It pays to think about organization of resources on kubernetes because in time you will have too many to keep in your head and reason about. Labels are great for doing this.

Labels are also used by resources to find resources to interact with and act on.

Labels make searching for groups of items easier.

Choose Label values wisely! if you ‘app’ label has some implementation detail in it, it will become obsolete when implementation changes. You dont want a pod called ubuntu-pod that actually runs on centos!

Conclusion

Labels are just one of the ways to organize your kubernetes cluster. Organization is the most important aspect of software engineering because code bases grow, number of services grow. If you dont figure out how to handle the complexity by grouping and categorizing, then very soon the complexity will overwhelm you.