Kubernetes is an open-source container orchestration platform that automates containerized applications’ deployment, scaling, and management. In recent years, Kubernetes has become a standard for organizations adopting cloud-native architectures and containerization technologies.
As organizations adopted Kubernetes, many other tools were created to help teams use it due to its complexity. Two tools most organizations use are Kustomize, a configuration manager for Kubernetes, and Helm, the package manager for Kubernetes. Helm and Kustomize provided solutions to the struggles of managing and deploying Kubernetes applications.
In this article, we will discuss Helm and Kustomize, what you can do with them, how to use them, and what are the differences between these tools.
We will cover:
Helm is the de facto package management solution for Kubernetes. A package manager automates the process of installing, upgrading, configuring, and removing software packages. Like Yum/RPM/APT in the Linux ecosystem and Chocolatey/Homebrew in Windows/Mac machines, Helm simplifies the software installation lifecycle in Kubernetes.
Accepted into the Cloud Native Computing Foundation (CNCF) on June 1, 2018, Helm is currently at the Graduated project maturity level. A project at the CNCF Graduated is considered to be stable, widely adopted, and production-ready, attracting thousands of contributors.
With Helm, you can define, install, and upgrade complex Kubernetes applications using a single command rather than manually creating and managing all the necessary Kubernetes objects yourself. Helm accomplishes this by providing a templating engine that allows you to define the components of your application as Helm charts, which can then be easily installed and managed. Helm charts can also be shared and reused, making it easier to distribute and collaborate on complex Kubernetes applications.
Example of a Helm Chart
Helm Charts are packages of pre-configured Kubernetes resources. A Helm Chart contains all the necessary information to deploy a specific application or service, including the Kubernetes manifests, environment variables, and other configuration settings.
A chart is organized as a collection of files inside a directory. The directory name is the chart’s name (without versioning information). For example, as shown on the Helm documentation, a chart describing WordPress would be stored in a wordpress/ directory with a structure that matches the image below.
In the above image, Helm reserves the use of the charts/, crds/, and templates/ directories.
The Chart.yaml file is required for a chart and contains the following fields as in the image below.
How to use a Chart Registry
When you create Helm charts, you store them in chart repositories hosted in any OCI (Open Container Initiative) container registries, either on a local system or online. The way by which you would host a Chart on a registry is dependent on the particular registry. See this Helm documentation on hosting on several registries.
Use the following command to log in to a registry with the Helm CLI installed:
$ helm registry login [host] [flags]See the helm registry login documentation for all flag options. To log out, you use the helm registry logout command.
Download a repository in a registry:
$ helm pull [chart URL | repo/chartname] [...] [flags]Using the above command, it is also important to check the registry documentation to be sure you have all the right command sequences. See the helm pull documentation for all flag options.
Chart versioning
Helm chart versioning is the process of assigning unique version numbers to different releases of a Helm chart.
Every chart must have a version number. A version must follow the SemVer 2 standard. Unlike Helm Classic, Helm v2 later uses version numbers as release markers. Packages in repositories are identified by their name plus version.
For example, an httpd chart which version field is set to version: 1.2.4 will be named httpd-1.2.4.tgz.
Kustomize is a configuration management tool for Kubernetes that allows users to customize and manage deployments, services, and other Kubernetes objects using declarative configuration files. It enables you to create different versions of a Kubernetes application without duplicating YAML manifests or creating multiple copies of the same deployment.
With Kustomize, you can define a base configuration for a Kubernetes application and customize it with different overlays for different environments or use cases. Kustomize uses patches to modify the base configuration and apply the changes to create a customized application version.
Kustomize provides a flexible and efficient way to manage Kubernetes configurations and reduce duplication of configuration files, making it easier to maintain and manage Kubernetes applications across different environments.
How to use Kustomize
To use Kustomize, in the directory containing your YAML resource files (deployments, services, configmaps, etc.), you create a kustomization.yaml file.
For example:
~/helloWorldApp
├── deployment.yaml
├── kustomization.yaml
├── configMap.yaml
└── service.yaml
The kustomization.yaml file would declare the above resources and any customization to apply. For example, adding a common label as in the kustomization.yaml file below.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
name: arbitrary
commonLabels:
app: hello
resources:
- deployment.yaml
- service.yaml
- configMap.yamlTo apply this customization, you run the following command:
$ kubectl apply -k ~/helloWorldApp As mentioned earlier, Kustomize enables you to create and manage different Kubernetes applications in different environments without duplicating YAML manifests. To do so, you create an overlay directory for each environment.
For example, you could create an overlay/dev directory for the development environment to modify a base configuration.
Inside this directory, create a kustomization.yaml file and add a patch to modify the base configuration. The patch should only include the changes necessary for the specific environment. You would repeat this step for each overlay you need.
The file structure of your Kubernetes application will now be as below:
~/helloWorldApp
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ ├── configMap.yaml
│ └── service.yaml
└── overlays
├── development
│ ├── cpu_count.yaml
│ ├── kustomization.yaml
│ └── replica_count.yaml
└── production
├── cpu_count.yaml
├── kustomization.yaml
└── replica_count.yaml
To apply the overlay/dev, you run a command similar to the below:
$ kustomize build ~/helloWorldApp/overlays/dev | kubectl apply -f -Helm and Kustomize are two popular tools in the Kubernetes ecosystem for managing and deploying Kubernetes applications. While both tools have similar goals, they approach the problem differently.
Here is the comparison table between Helm and Kustomize:
| Kustomize | Helm | |
| Native Kubernetes integration | Yes | No |
| Ease of use | Simple | Complex |
| Approach | Overlays | Templates |
| Declarative/imperative | Declarative | Imperative |
| Packaging | No | Yes |
| Version control/Rollbacks | No | Yes |
Integration in Kubernetes
Helm and Kustomize are both built for Kubernetes. Unlike Kustomize, Helm is not included in a standard Kubernetes installation, so you must install it from its binary releases, script, or via a package manager. The actual installation is simple. However, introducing a new system to your architecture brings security and complexity management concerns.
Kustomize, on the other hand, though included with Kubernetes, is an additional learning curve, and your team has to consider whether it solves their problem for them. If your team struggles to manage YAML configuration files across separate environments, Kustomize is the best solution. However, if your goal is to simplify the software installation lifecycle in Kubernetes or share your application easily with others, Helm is the best solution.
Kustomize and Helm aren’t really in a contest with each other, and they can be used together. You will learn how to use Kustomize with Helm toward the end of this article.
Complexity and Security
As stated earlier, Helm introduces complexity to Kubernetes architecture. This is because Helm is a more complex tool than Kustomize, as it provides a full package management system with a templating language, dependency management, and versioning. Kustomize is a simpler tool that focuses on customizing existing manifests.
Regarding security, seeing Helm is external to the original Kubernetes design, it can introduce security risks. HelmV2 (as of the time of writing this article, Helm is on 3.11.1) temporarily introduced major security headaches by incorporating a module that could expose Secrets in plaintext.
Though the risks have been resolved, you still have to keep in mind the need to monitor all external variables handled by Helm.
Flexibility
Kustomize provides more flexibility than Helm in the customization of Kubernetes manifests. It allows you to apply patches to existing manifests and generate customized versions of those manifests for different environments.
Helm templates, on the other hand, are more rigid in structure and require a certain level of familiarity with the templating language to use effectively.
Read also: Helm vs. Terraform.
Helm and Kustomize can help you manage your Kubernetes applications more efficiently. There are several scenarios where you might want to use Helm and Kustomize together, and there are:
- When you don’t own and control the Helm chart: It’s common to pull and use a Helm chart somebody else published in a Helm repository. What if you want to modify something in the manifests? Kustomize makes this easy.
- When creating Secret and ConfigMap resources: When working with Secrets and ConfigMaps, you obviously don’t want them baked into your Helm charts. With Kustomize, you can create the resources after Helm has inflated the charts.
- When you want to edit fields in multiple resources simultaneously: In certain instances, you may want to force all (or a subset of) resources to a namespace or apply a label to these resources. You wouldn’t normally want it in your Helm charts, but Kustomize can overlay this setting over your resources.
There are two main ways to use Helm and Kustomize together, and two of them can’t be done simultaneously.
- Using
helm templateto generate the manifests, and then Kustomize to do the patching. The downside is that Helm doesn’t manage any releases. - Using
helm install(orhelm upgrade --install) and having Kustomize modify the manifests before applying them in the cluster. With this method, you still benefit from Helm managing your releases and applications.
Kustomize and Helm are both powerful tools for managing Kubernetes applications. While both have similar goals, they approach the problem differently. These tools aren’t really in a contest with each other, and they can be used together
You can also take a look at how Spacelift helps you manage the complexities and compliance challenges of using Kubernetes. Kubernetes support in Spacelift is driven by Kustomize, with native support in kubectl.
While there is no native support within Spacelift for Helm, you can use the helm template command in a before plan hook to generate the Kubernetes resource definitions to deploy. Find out more about how Spacelift works with Kubernetes, and get started on your journey by creating a free trial account.
The Most Flexible CI/CD Automation Tool
Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.
