Kubernetes: Naming Things

An old saying goes something like this: there are only two hard problems in computer science, namely cache invalidation, naming things, and off-by-one errors. We will focus on the naming things topic in the context of Kubernetes, here.

As YAML, erm, Kubernetes engineers we are painfully familiar with structures like the following:

type: human

id: mhausenblas.info

labels:

name: Michael Hausenblas

family-role: dad

What did I just say? Well, I just described myself. Why did I not use "Michael Hausenblas" as the thing that identifies me? Well, it's ambiguous. Believe it or not, there are other folks running around with the same name, but only one who owns the domain mhausenblas.info. I consider my name a property (a label, if you wish) of the entity that is identified by mhausenblas.info. Next, a thing I try to explain to our kids (and keep failing): my name is not "dad". That's just a role I play in the context of our little family of five. There are many dads out there, but in the context of our family it's probably fine to expect me to show up when you yell "daaaaaaad" through the house. So both my name and my role (in the context of the family) are properties of my person.

OK. Let's talk about Kubernetes again.

Reference By Property

While Kubernetes uses name for the ID, the rest of the observations from above are still valid. Either you give the thing you're creating (deployments, services, etc.) yourself a name, or—if they are auto-generated—Kubernetes will do that for you. Let's have a look at a concrete example:

$ kubectl run webserver --image=nginx

deployment.apps/webserver created
$ kubectl get pods \
 --selector=run=webserver \
 --output=jsonpath={.items[*].metadata.name}
 webserver-5748cdbbfc-7vn5j
 

Woah, what just happened? I wanted to know the name of the pod that kubectl run—better say, the deployment it caused—created for me. So, I'm starting out with stuff I know. I know that when I do a kubectl run then the deployment, replica set, and pod(s) it creates will be labelled with run=$NAME. So I used that as a selector, filtering for pods with that label and then using a JSONPath template to pull out only its name, which is, in this case webserver-5748cdbbfc-7vn5j.

How is that useful you ask? Well, very often you'll need access to a pod, for example if you want to do a port forward, and in order to script that you need the actual pod's name.

Now that we understand how we can name and pick out individual resources, let's move on to the topic of ownership.

Owners and Garbage Collection

There is a whole class of objects in Kubernetes that has owners and with it comes the topic of garbage collection. That is, who is going to clean up the mess after you. Let's get back to our example from above. Who's owning (or: supervising) our little pod?

This is how you could find it out:

$ kubectl get po \

-l=run=webserver \

-o=jsonpath={.items[*].metadata.ownerReferences[*].name}

webserver-5748cdbbfc

Notice how I got lazy? I don't say get pods but get po and also I use -l rather than --selector, etc. … you know, less to type ;)

So we got another name, webserver-5748cdbbfc; also, compare that with the pod's name of webserver-5748cdbbfc-7vn5j, notice something? I happen to know that this resource is of type replica set, so I'm querying it like this:

$ kubectl get rs webserver-5748cdbbfc

NAME DESIRED CURRENT READY AGE

webserver-5748cdbbfc 1 1 1 5m

We could continue this game and discover so that at the top of the ownership hierarchy there is a deployment called webserver, which name is, unsurprisingly, derived from what we used in kubectl run earlier on.

What happens if we delete said deployment? Well, what would you expect to happen? At least I'd expect that the command gets rid of the deployment and all the resources it owns. And guess what? That's exactly the default behavior which you can change by appending --cascade=false to the delete command. Note that there are also exceptions to said garbage collection rule, for example with jobs or in the case of a stateful set, where deleting it won't delete its associated volumes.

Hope this was useful and you now better understand and appreciate the power of "reference by property" through labels and start experimenting with it a bit, in case you haven't yet.