Labels in Kubernetes are in a weird place. Few people talk about them. Sometimes they might even feel like a minor afterthought.
When starting out, you might not appreciate them enough. Sure, you can’t get around labeling your pods a little, otherwise they won’t get picked up by services and deployments won’t work – but that’s pretty much it.
If You’re Not Madly in Love with the Elegance of Labels, You’re Missing Out
Labels are EVERYWHERE in Kubernetes. They keep everything together and they can help make your daily Kubernetes life a lot easier. Especially when the number of workloads and users grow, you have to get smarter with your labels and use more of them. It’s best to start early, before you’re forced to do so when it’s past ’tricky to use’ and well into ‘frustrating’ territory.
Labels can help you feel in control when interacting with your cluster through kubectl, to automate tasks and to save a lot of time when getting to the bottom of issues.
Label Dimensions
You can think of each label name (or key), as a distinct dimension in which your Kubernetes resources differ from each other. You should try to apply labels to pretty much all resources you create and use. Your future self will be grateful.
This will enable useful operations for which you need to group your resources in a certain way across one or more of your label dimensions, which would not be possible if you did not take care of being explicit about them beforehand.
I took the time to look through popular Helm charts, blog posts and videos to gather a few examples of label usage in the wild. This way you can see what other people are using and get inspired to rethink what might work for you. Here are a few label dimensions, with key and value examples:
- Application name (app: nginx, haproxy)
- Environment name (environment: dev, env: test, qa, prod)
- Release types (release: beta, stable, 0.1.0)
- Deployment metadata (deploy: canary, blue, green)
- Owner/person responsible (owner: bob, team: rocket)
- Interaction types (status: serving, unhealthy, investigating, manual, debugging)
- Abstract part of the architecture or tiers (tier: frontend, component: backend, cache, worker-web)
- Application-specific metadata (partition: client-x, zone: eu, role: master, slave, shard: A)
- Release tracks (track: daily, weekly)
- Helm chart specific (chart: prometheus–1.0, heritage: Tiller)
Of course, there are limitations when working with labels. Is there information which does not fit into the label syntax constraints, you might want to look into annotations. Keep in mind that you won’d be able to use them to select resources as that’s not what they are for.
Usecases
This really depends on your application and tasks you will need to take care of in the future.
Think about your usual interactions with Kubernetes. Is there a way to make them more elegant? Have you considered a certain way of doing things which did not seem easy to implement? Could you have been missing the power of labels?
Here are a few upsides of using labels to their full potential:
- Kubectl commands get simpler and can be more powerful
- Modern deployment processes are enabled and become more robust
- Getting more in-depth insight from monitoring tools
- Enhance your logs with additional info
- Automation tasks are easier to implement
Get creative! Labels are a tool you should use and appreciate. From the Kubernetes docs:
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users
In Conclusion
Have you been using labels as an afterthought? Did you find a few label dimensions which you have been missing, or use cases which you’d like to see implemented in the future?
Consider labels as the powerful tool which they are, and be sure to use them with all of your resources. Think about what operations you might need in the future, and what could be easier when using labels. Prepare by adding more labels to your deployed resources. Even if it’s just a few. Especially if they are easy to add right now.