How to Set the Component/Part-of Values of Kubernetes?fleeting
how to set the component value of kubernetes
The value app.kubernetes.io/component and the value of app.kubernetes.io/part-of are meant to describe something that goes beyond the definition of the component itself.
In the given exemple, mysql has the values
It might have made sense in a pre-helm era, one single team might develop all the resources with the big picture in mind, and then have enough knowledge to write down the values of component and part-of.
Now that helm is everywhere, the development of charts is made by separate people that don’t have the big picture in mind. Some people developed the chart to deploy mysql and those obviously don’t know whether mysql will be used in wordpress or in something else.
I also believe that the value of component has the same property. Some people might argue that mysql is a database and that does not depend on the big picture. I agree with this, but I claim that this is not always the case.
Let’s take another example to illustrate this: redis.
Naively, I would also pus component=database, because redis is a key value datastore. Yet, in some cases, redis might be used to only to take advantage of its pub/sub implementation and something else could be used as database (like mysql). In that case, I would argue that the redis resources should have the value component=message-broker.
Therefore, I think that, even if it is less obvious, the value of component also makes sense only from the point of view of the developer of a higher level object.
As a conclusion, when writing a chart of a piece of technology, I advise not to populate component and part-of and leave room for templating them so that the higher level charts that will use them will be able to populate them in a sensible way. At least, if you want to provide something, I suggest to use the name “main”, because if you only have one component in a chart, it is likely to be the main of itself.
how it’s done at bitnami’s?
Let’s use again the example of mysql. Against what is suggested, it does not provide a component=database.
Instead, it looks like the templates are split into components inside the chart, but the chart itself does not provide any notion of component. For example, there is the component secondary that aggregates all the resources that are in the directory secondary. Same for primary. And prometheus is part of a metrics component.
It makes sense from the point of view of a single chart that has no dependencies.
Let’s take a look at a more complicated example: wordpress. It only provides the metrics component for prometheus.
It has mariadb as dependency, but nothing about component or part-of. The chart of mariadb is basically the same as the one of mysql.
This corroborates the idea that even though the component/part-of lables made sense in a pre-helm era, they hardly make sense with a use of helm as long as it does not handle them built-in.