Friday, December 27, 2024
Google search engine
HomeGuest BlogsHelm vs Kustomize: Head-to-Head Comparison

Helm vs Kustomize: Head-to-Head Comparison

Introduction

Kubernetes natively offers the core tools necessary to manage application deployment. However, while applying raw YAML manifests is a straightforward process, developing in a microservice environment quickly spirals out of control with the number of deployments necessary to support an entire system.

This article compares two popular tools that aim to simplify application deployment management – Helm and Kustomize.

Helm vs Kustomize: Head-to-Head ComparisonHelm vs Kustomize: Head-to-Head Comparison

Helm: Key Features

Helm is a package manager for Kubernetes. It assists in installing and managing Kubernetes applications by employing helm charts, packages containing YAML files modified using Go template language, and template functions from the Sprig library.

Note: Helm is a feature-rich tool that performs many functions outside the scope of this article, such as packaging, hooks, and rollbacks. The article focuses on Helm features comparable to Kustomize. To learn more, read our article What is Helm?

By employing the templating and dynamic values, Helm offers the ability to fine-tune a configuration throughout the software development lifecycle.

With the introduction of Helm 3, Helm stopped depending on Tiller for dynamic configuration file generation. This eliminates one of the main security concerns of Helm 2 – the broad permissions granted by default for everyone with access to Tiller. Helm now features privileged access management components with Role-Based Access Control (RBAC) and Custom Resource Definitions (CRD).

Another useful property of Helm templating is encapsulation. The YAML definitions of Kubernetes objects, such as Deployment, Service, ConfigMap, or a Kubernetes Secret, can be encapsulated in a single template. This property is helpful for deploy-time configuration.

A simple helm chart consists of:

  • A Chart.yaml file that declares the chart.
  • A values.yaml file that contains chart parameters to be used with templates.
  • A template directory containing template files for building the contents of the chart.
Helm chart directory tree structureHelm chart directory tree structure

A template file has the structure of a YAML file, but it also contains template variables that are replaced on deployment with the values provided in the values.yaml file.

This is what the contents of a typical deployment.yaml look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.test }}
  labels:
    app: {{ .Values.test }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.test }}
  template:
    metadata:
      labels:
        app: {{ .Values.test }}
        tier: web
    spec:
      containers:
      - name: {{ .Values.test }}
        image: {{ .Values.test }}     
        ports:
        - containerPort: 8080

In the example above, Helm looks into the values.yaml file for the value of the test variable. The relevant values.yaml file contains the variable definition:

test: default

Based on the values.yaml definition, Helm builds the following deployment.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default
  labels:
    app: default
spec:
  selector:
    matchLabels:
      app: default
  template:
    metadata:
      labels:
        app: default
        tier: web
    spec:
      containers:
      - name: default
        image: default     
        ports:
        - containerPort: 8080

Helm features the ability to override the values in the values.yaml using the --set flag when issuing build commands in the CLI.

It also includes the helm lint command that examines a chart for issues, verifying it has been designed according to the standards.

Note: To find out more about Helm charts, read How to Create and Deploy a Helm Chart. To get you started with Helm, phoenixNAP provides a free downloadable Helm commands cheat sheet.

Kustomize: Key Features

Kustomize is a tool that uses layers and patches instead of templates to customize Kubernetes objects. It introduces the kustomization.yaml manifest file, in which users store deployment-specific configurations.

The tool is built into kubectl as of version 1.14, which means it is now native in Kubernetes. However, you can also install it independently.

With Kustomize users can manage any number of Kubernetes configurations, each with its distinct customization, using the declarative approach. It allows developers to define multiple versions of an application and manage them in sub-directories. The base directory contains the common configurations, while sub-directories contain version-specific patches.

Kustomize tool directory tree structureKustomize tool directory tree structure

Each directory contains its kustomization.yaml file that specifies what changes need to be made to the configuration and which resources should be used. For example, the following kustomization.yaml file adds a common label app:test to both deployment.yaml and service.yaml in the base directory:

commonLabels:  
  app: my-wordpress
resources:
- deployment.yaml
- service.yaml

The changes are then applied by typing the following command in the command line:

kubectl apply -k base

The command is different if Kustomize is used as a standalone tool:

kustomize build base | kubectl apply -f -

Helm and Kubernetes: Pros and Cons

Pros

  • Helm offers many features that go beyond simple app deployment configuration management, such as packaging, hooks, and rollbacks.
  • It simplifies app installation by allowing users to set defaults that they can further configure with the values if necessary.
  • Helm is well known to developers, it has many users and great online support.
  • The Helm template functions make it possible to introduce conditionals and loops, define helpers and access the Sprig functions library.
  • Most commonly used applications have their Helm charts available online, which saves time and increases productivity.

Cons

  • Helm adds more abstraction layers and has a steep learning curve.
  • It limits the customization of applications to pre-existing configuration options.
  • Templates are error-prone, especially in terms of the proper alignment of YAML.
  • Helm is not supported natively in Kubernetes, which creates an external dependency.
  • It is often imperative. Helm injects values into templates at runtime, so if the template changes, the system may diverge from what the user expects.
  • Charts still require runtime customizations, making them difficult to manage when implementing the CI/CD pipeline.
  • Less readable templates inevitably lead to less customizability over time.
  • It suffers from security problems stemming from the lack of visibility and transparency during the installation of apps.

Kustomize and Kubernetes: Pros and Cons

Pros

  • Kustomize is simple to use.
  • It is declarative, aligning with the Kubernetes philosophy.
  • Kustomize supports an inherited-base model, which makes it scale better than Helm.
  • Using the native version integrated into kubectl eliminates external dependencies.
  • It makes it easier to use off-the-shelf apps.
  • It uses only plain YAML files.

Cons

  • Kustomize does not offer many features.
  • It is not designed to follow the DRY (Don’t Repeat Yourself) principle.
  • Users must manually declare resources and patches in kustomization.yaml, and the file must be manually updated whenever a new file is added.
  • The native version embedded in kubectl is much older than the current standalone version.
  • Online support for Kustomize is difficult to find.

Kustomize vs Helm: Comparison Table

Feature Helm Kustomize
Templating Yes No
Overlays No Yes
Packaging Yes No
Validation hooks Yes No
Rollbacks Yes No
Native K8s integration No Yes 
Declarative nature Mostly imperative Yes
Visibility and transparency Weak Strong

How to Choose?

To decide whether to opt for Helm or Kustomize, consider the following:

  • Choose Kustomize if you are planning to write all the configurations on your own, and you possess a good understanding of how YAML works. While Kustomize allows you to perform complicated customizations quickly, it requires you to be able to visualize how the patches and layers fit together.
  • On the other hand, if you want your developers to be able to add new apps and services in a safe and easy way, creating Helm charts is a better solution.
  • Another reason to choose Helm is the need to decrease the amount of time you spend with YAML files. Helm templates have arguments that make it easier to understand how services work without delving too deep into YAML.

Given that both Helm and Kustomize offer tool-specific benefits and complement each other well, the best course of action would be to use the two tools side by side. Helm is particularly useful for packaging, sharing, and installing apps that are well-defined, while Kustomize works best for last-minute modifications of existing Kubernetes apps.

Conclusion

This article provided a head-to-head comparison between Helm and Kustomize, two tools for Kubernetes app deployment configuration. To read more about useful Kubernetes tools, read 15 Best Kubernetes Tools for Deployment, Monitoring, Security, and More.

Was this article helpful?
YesNo

RELATED ARTICLES

Most Popular

Recent Comments