Building Robust Helm Charts

Summary

Building robust helm charts In my current work, there is often the need to deploy a similar application stack in various configurations, to several environments. Each configuration may vary in terms of scale, uptime requirements and feature flagging. Due to a lot of flux in infrastructure set up, each environment is also not equivalent. On top of this, there are obviously financial requirements to run all of this as cheaply as possible. Kubernetes and helm templating are valuable tools in this situation, they allow us to create a configuration blueprint with the details abstracted in values.yaml files. Use helm’s built in linter Let’s start with the basics, helm provides a helm lint command which performs checks YAML syntax Template rendering Missing or misnamed required files Best practice violations You can run this with your different values.yaml files to ensure that all your configurations are compliant. It’s also a good idea to use the helm template command to actually check that helm is able to render your templates. Parallels with front end templating I like to compare helm templating with html templating tools like JSX. This allows front end developers to create reusable components usable throughout pages of a web application, A button component for example can have many states, primary, secondary, loading, disabled, light or dark mode. Each state may also look different depending on the size/type of device your are browsing the site with. Each of these states represents differences in many parameters (font size, colour, gradient, opacity, border, padding, margin, width, height, etc). These complexities are abstracted away giving the consuming code the list of states to chose from, so that they can write code like this. <button type="primary">Click Me!</button> Under the hood of course many aspects of the CSS or HTML code will be impacted by the change of state so you often end up with different parts of the markup having conditionals on the same check. cons...