The Perils of Helm: Unhygienic Templating and Configuration Languages in K8s

Have you ever experienced the frustration of dealing with unhygienic string templating in a whitespace-sensitive language? If you have, then you can relate to the pitfalls of Helm, the leading Kubernetes package manager. In this article, we’ll explore the insights gained from three years of working with Helm and delve into the challenges of its templating system and the choice of YAML as a configuration language.

The Unhygienic String Templating Nightmare

One of the major pain points with Helm is its unhygienic string templating feature. This feature, which utilizes a whitespace-sensitive language, has left many users astonished. As one user exclaimed, “Unhygienic string templating of a whitespace-sensitive language is a truly new hell for those who have not experienced it before.”

But why is this decision so astonishing? Another commenter provides some perspective, stating that unhygienic templating and the lack of template and serialization boundaries have been consistent disasters in the field for many decades. The sentiment expressed is that the overuse of text-based DSLs and configuration languages, not just in Helm but in DevOps YAML/config language mess in general, may turn out to be a giant mistake. These “declarative” config languages are optimized for simplicity at the beginning, but as the complexity grows, they start to appear inadequate.

Seeking Alternatives: The Quest for Better Configuration Languages

Given the frustrations with Helm’s templating system and the limitations of YAML, users have begun exploring alternatives and proposing solutions. Some users suggest using languages like Python or JavaScript for Kubernetes configuration. While Helm itself does not support these languages, there are alternatives like Pulumi that allow using Python and JavaScript for provisioning.

Another alternative that has gained popularity is JSONnet. JSONnet is a constrained programming language designed specifically for configuration, and it has the advantage of always generating valid JSON. Users have found success with JSONnet in building K8s tooling and generating JSON for APIs.

Another mention goes to ksonnet, a powerful alternative to YAML for configuration. However, it didn’t gain much traction in the K8s world, possibly due to its complexity. Nevertheless, some users believe that it could be a future solution worth exploring.

Configuration Languages: Finding the Right Tool for the Job

The choice of configuration languages is always a matter of debate. While YAML has found favor with many users for relatively simple configurations, there are differing opinions on its suitability as a true configuration language. One user points out that YAML is primarily a tree serialization format with some human-targeted ergonomic features, rather than a proper configuration language. They argue that for complex configuration scenarios, even XML can be a better alternative.

Another user echoes this sentiment, stating that configuration languages like YAML need proper schema validation and types to avoid the pitfalls of unstructured templates. While some validation exists in K8s APIs, there are frustrating gaps that can lead to errors and difficulties in troubleshooting.

In the quest for better configuration languages, the community has come up with various solutions. Some advocate for tools like CDK8s, which brings the power of programming languages to Kubernetes configuration. However, it is important to strike a balance between simplicity and complexity, ensuring that the chosen configuration language is suitable for the task at hand.

Conclusion: Learning from the Helm Experience

The experience of working with Helm, the leading Kubernetes package manager, has provided valuable insights into the challenges of unhygienic templating and the limitations of existing configuration languages. The frustrations of dealing with unstructured templates and the lack of proper schema validation have prompted users to seek alternatives and propose solutions.

While YAML continues to be widely used, there is growing awareness that it may not be the ideal choice for complex configuration scenarios. The search for better configuration languages that strike the right balance between simplicity and flexibility is ongoing.

As we navigate the landscape of Kubernetes and DevOps tooling, it is important to critically evaluate the choices we make and learn from the pitfalls and challenges encountered along the way. Only then can we progress towards a more efficient and robust system that empowers developers and operations teams alike.

So, let’s keep exploring, experimenting, and pushing the boundaries to create better tools and practices for the fascinating world of Kubernetes and cloud-native development.

Keep calm and K8s on!