Over on Twitter, Greg Swift brought up an issue of the long Kubnerntes label names.
These labels names are not a Helm-ism. Rather they are called out in the Kubernetes documentation. This is a Kubernetes-ism. One that has a lot of valuable information in the context and reasoning.
Where Did They Come From
For a long time there was no documentation or standard practice on these sorts of labels. That meant that different people used different conventions. This was terrible for interoperability between tools.
One of the goals of the now completed Application Definition Working Group (App Def WG) was to make interoperability better. This would help people who wanted to deploy with Helm and view the app in a dashboard. Or, it would help people if they wanted to migrate between tools. Or any number of other actions. If multiple tools speak the same labels it’s good for interoperability and end-users.
We’ll come back to end-users in a moment because they are really important.
In the labels the app.kubernetes.io is a prefix. The prefixes need to follow DNS rules and the long standing pattern is to spell out Kubernetes rather than use the shorter k8s.
In the documentation on labels it also says:
If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, or other third-party automation) which add labels to end-user objects must specify a prefix.
Whether to prefix or not was heavily discussed. It wasn’t just a matter of policy. It was about actions that cannot be undone and UX.
When something takes over an item in the global space, without using a prefix, it cannot be easily changed later. That name is in use, has meaning, needs to follow a deprecation policy, and users have expectations on it staying around. This was noticed and talked about.
After performing some research which looked at what metadata tool developers used or wanted to use, a list of names was created and discussed. The list was filtered down, discussed, analyzed, and picked at. Eventually, the final output was turned into the Recommended Labels documentation.
The recommended labels is what Helm moved to. It was a move designed to make Helm more interoperable with other tools.
User Experience (UX)
If you use these longer label names with kubectl you know the experience isn’t great. It was a step back. The App Def WG knew that. So, why would they make some UX worse?
Kelsey Hightower, over in a Twitter thread made an interesting comment:
most people can only relate to kubectl, which has its own way of doing things.
A lot of people who have been around Kubernetes are kubectl users. I would argue for Kubernetes to really grow this is going to change. This is something I started to consider when members of the App Def WG brought it up (I wish I could remember who that was).
At the Kubernetes Contributor Summit in Seattle 2018, Brian Grant gave a talk on a Technical Vision for Kubernetes.
In the talk he called out where he believed Kubernetes was in the technology adoption life cycle. After reflecting on this, I think Brian is about right on the location of Kubernetes. We can debate about a little to the right or left but the general area is about right, in my opinion.
For people who use Kubernetes regularly this can be a hard location to consider. Especially for people who pour a lot of their weekly time or have been around the project a long time.
When Kubernetes is adopted by the majority, especially if it gets to the late majority phase, the interactions with the API and the metadata it stores will be different. The App Def WG was not designing for the tools we have today but for the tools that will come. The tools we need to come for the majority.
These tools may be other command line clients, more graphical user interface (GUIs), interactions with other systems, and much more.
This doesn’t mean that kubectl will be used less. It should grow in use but be a smaller percentage of the overall API use.
If you’re not sure why people would use other tools than those we have today, I would challenge you to learn about the needs of the majority.
As better tools show up for many of the people we hope will come join the Kubernetes party they will need to inter-operate. These labels will hopefully help them do that.