3 ms·

So you write the whole configuration of the helm chart in your values.yaml? At this point I have to ask why one should not just write the helm-chart itself? Wha

• eschatology 3y ago
  Less boilerplate, centralization, leading to less maintenance burden A universal helm chart like this allows a lot of defaults to be set, with the values containing only the necessary changes to get the code running in the cluster (and small adjustments, as needed). When you need to add/change/remove something from all services, this can all be done through the universal chart, greatly reducing maintenance friction of getting changes through to all services from one location. In a large enough organization, there can be hundreds of services with almost exactly the same chart with the same set of things. I think creating a helm chart makes sense if you're planning to publish it and have it used by multiple, different entities that don't own the project (think about any open-source projects really). However for internal, closed-source services, the same entity owns the code, the chart, the values, and the deployment. It adds a lot of boilerplate and there's really little reason to maintain and publish a chart as an artifact for each service.