Has Kustomize killed Helm for Kubernetes deployments?

Has Kustomize killed Helm for Kubernetes deployments?

The king is dead, long live the king!.. Is it!? Why did Kustomize, and other configuration-management approaches fail to replace Helm?

Introduction

Since Kubernetes was released in 2014, developers have struggled to build a direct replacement for Helm. That’s because Helm offers an abstraction that allows you to deploy complex applications by describing them in terms of charts. It’s very powerful and flexible but also requires you to use a specific toolchain and understand how it works.

This has made it difficult for developers to adopt Helm, especially those who are new to Kubernetes or don’t want to learn about its inner workings or the Helm ecosystem.

If you are an entrepreneur or the CEO of an enterprise that has decided to use Kubernetes for its cloud-native application platform, then Kustomize may be your new best friend. Kubernetes is already a relatively complex platform with dozens of different ways to configure and deploy applications. Kustomize makes it much easier for developers and ops engineers alike to get started by automating many of these provisioning steps. If you’re familiar with configuring Kubernetes objects via kubectl, then Kustomize use will be very transparent —you’ll just need to add some additional configuration files, files with only the customization you need.

Spoiler alert:

Vanilla kubectl (after customizing)

kustomize build la-rebelion | kubectl apply -f -

With Helm

helm install --upgrade la-rebelion my-rebel-app

When I asked one user about their experience with Kustomize, they told me: “Kustomize has been a godsend for us. We used Helm before because it was simple and easy but now we have switched over completely because our devs can make changes immediately on their laptops without waiting 15 minutes every time they want to make even minor changes."

How did we get here?

Helm was originally developed by Deis and donated to the Cloud Native Computing Foundation (CNCF) in 2016. This project was built on top of Tiller, which is an alternative to kubectl for managing Kubernetes clusters. Helm is a popular configuration management tool that allows you to create applications or services on top of your cluster with different versions and environments (e.g., dev, stage, prod). It was developed as an extension of the Kubernetes API and uses YAML files to describe your application configurations. Helm has been widely adopted by developers because it simplifies deployment processes while still allowing them to take advantage of core features offered by Kubernetes such as container management tools like Docker Engine or rkt support, service discovery using DNS/KubeDNS, etc...

Kustomize is another popular CLI tool created by Google that allows users to customize their containerized applications before deploying them into production environments using the same underlying technologies used by Kubernetes itself like containers & pods under different namespaces/labels etc. Kustomize lets users configure their images without needing access rights into private repositories containing source code; they can also easily customize existing images via simple commands such as kustomize apply-diff -f ./diff_files/* --image=my_image. How could you do the same with helm? Changing the values.yaml and only if your chart support the variable, otherwise, you need to change the template directly (which is awful, isn't it?).

What is Kustomize?

Kustomize is a tool for managing Kubernetes objects. It allows you to create custom resources based on existing ones, like Kubernetes deployments, namespaces, and pods.

Kustomize was born from the need to customize the deployment process of applications running on Kubernetes without having to write code in other languages like Python or Go. Kustomize uses YAML (YAML Ain't Markup Language) as its configuration language and works natively with Kubernetes API server API and client libraries to achieve this goal. Based on your raw, template-free YAML files, kustomize lets you customize these files, leaving the original YAML untouched and usable as is.

How do I get started with Kustomize?

To get started with Kustomize, you'll need to install it in your cluster. You can do this by running the following command:

The following script detects your OS and downloads the appropriate kustomize binary to your current working directory.

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash

How does Kustomize work?

Think of Kustomize as a tool for managing Kubernetes objects (pods, statefulsets, configmaps, etc.). It works by creating YAML files that describe the changes you want to add and then using those YAML files to generate a customized Kubernetes object. Kustomize works by creating a directory for each Kubernetes object that you want to customize. Inside this directory, it creates a YAML file called kustomization that contains the specification for how this object should be created. It then runs kubectl apply with the customized files generated, i.e.: kustomize build ~/laRebelionApp/overlays/production | kubectl apply -f -.

How does Kustomize differ from other tools like Helm? Helm is a package manager for Kubernetes. It lets you specify in an easy way what kind of packages (like apps or services) and resources (like databases, storage services, etc.), are combined into so-called “charts” and shared on GitHub repositories. You can then download these charts into your cluster, install them with helm install, update them with helm upgrade, and remove them from your cluster with helm delete.

{{- define "Templates.no.more" }}

No longer will you have to muck about with templates and charts. Kustomize can be used to create and customize Kubernetes application deployments with a standard YAML file and a few overlays.

You may have found yourself writing custom Kubernetes resources using Helm charts in the past. This process was tedious and error-prone, requiring you to write a manifest file for each resource that needed to be created. Kustomize is a CLI tool for creating and customizing Kubernetes application deployments based on the ksonnet project. Kustomize uses a standard YAML file and a few overlays to create and customize Kubernetes objects such as pods, services, ingresses, load balancers, and secrets.

What are the common use cases for Kustomize?

Kustomize is a YAML-based configuration file that can be used to create and customize Kubernetes objects. The most common use cases for Kustomize are:

  • Applying the same changes to multiple resources.
  • Easily apply a manifest across multiple cluster environments
  • Overriding fields in an object.
  • Leverage existing charts with all the features behind Kustomize.
  • Using custom objects and subresources
  • Merging of common fields into objects.
  • Kustomize has been used to create a single configuration file for deployment to multiple environments, and it is also used by many companies to create a common set of values that can be applied to production deployments.

Why did Kustomize, and other configuration-management approaches fail to replace Helm?

Helm, our beloved wannabe overlord, and best friend have been in the Kubernetes world for a very long time. It is popular, widely used, and has a large community behind it and is growing every day. Helm provides a simple way to install, update and manage Kubernetes applications.

It solves many problems in the Kubernetes ecosystem by providing a consistent way to build and deploy applications while abstracting away all the complexity of managing Kubernetes resources. While Kustomize might be able to do most of these things too (with some configuration), Helm is designed with all of these use cases in mind and therefore provides an easier experience for users who want to accomplish all of them at once.

In addition to this flexibility and power comes maturity: Helm was released before Kustomize or any other similar tooling existed so it had more time on its side when it came down to establishing itself as “THE” way of deploying apps on Kubernetes. Kustomize only came out three years ago and while it does have quite a few nice features (including being written entirely in Go), it doesn't have nearly as much name recognition as Helm does - even though both projects are open source! This doesn't mean that Kustomize will never become more popular than Helm though - just look at what Docker did during those six years!

Takeaway: Kustomize seems to be an incremental improvement over overlays but it is still not a silver bullet for customizable Kubernetes objects. The real benefit is that you are not tied to another abstraction.

As you can see, Kustomize is a good first step towards customizable Kubernetes objects. It is not a silver bullet for customizable Kubernetes objects because it does not provide the full power of Helm that users have become accustomed to. However, it has made an important improvement in that you are no longer tied to another abstraction.

If you are an end-user that requires to deploy Kubernetes applications, Helm may be your solution, because encapsulates all the complexity of Kubernetes resources into easy-to-use templates. If you are a developer or operator, who needs the full power of Kubernetes objects and APIs and agility to introduce changes constantly and fast, then Kustomize may be your solution.

For complex deployment, leveraging Helm has the same benefits that package managers had for the Kubernetes ecosystem. Software is more likely to be used if it can conveniently and effortlessly be installed, shared with other users, or removed.

Conclusion

This post is meant as an introduction to Kustomize and its capabilities. We did not touch on many more features here, but hopefully, this gives you a sense of how powerful the tool can be when used correctly.

This is not the only way to improve your configuration, there are many other ways to do it. You can use Helmee to leverage Helm Charts. Helmee is based on the same idea of Kustomize overlays', enabling you to do improvements because you don't modify the original resources directly not depending on the configuration that you don't control, nor own. You don't have to wait for a new version of an application to fix it but can just do the improvement right away.

Rebels are disrupters — they want to change things, and bring new insights and possibilities. ✊🏼

Join to "La Rebelion" community here to receive updates and insights about the cause, Kubernetes interactive lessons available, or register to helmee beta.

Share your thoughts and improvements with us!

Did you find this article valuable?

Support La Rebelion Labs by becoming a sponsor. Any amount is appreciated!