Helm is a template engine, it is operated by a third party.

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.

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.

When a templating engine used you

• create a boilerplate example of your file. From there you abstract away contents with known filters and within these abstractions you provide references to variables.
• These variables are normally abstracted to another file where you insert information specific to your environment.
• Then, on runtime, when you execute the templating engine, the templates are loaded into memory and all of the variables are exchanged with their placeholders.

Kustomize is an overlay engine, it is developed directly by the Kubernetes team, it is directly supported in Kubectl

• 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.

• Create a Kustomization.yml file. This file then points to two different things. Your Base and your Overlays. At runtime your Base is loaded into memory and if any Overlays exist that match they are merged over top of your Base configuration.

• This method allows you to scale your configurations to large numbers of variants more easily.

• It would greatly reduce redundancy and greatly improve manageability.

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:

You might want to use Helm and Kustomize together when:

• You don’t control the Helm chart - One of the benefits of Helm is that it’s considered the “package manager of Kubernetes”. It’s quite 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 simple.

• Different environments - One of the more natural uses of Kustomize is to have different configurations for different evironments. While you could achieve this solely with Helm, it would be a cleaner solution to maintain different environment kustomizations abstracted away from the Helm charts.

• Secret creation - When working with Secret and ConfigMap resources, you might not (and probably don’t) want them baked into your Helm charts. Having Kustomize create the resources after Helm has inflated the charts is a common way to inject this sensitive data in the cluster.

• Cross-cutting fields - In certain instances, you may want to force all (or a subset of) resources to a namespace, or apply a label to these resources. Typically you wouldn’t want to have that in your Helm charts, but Kustomize can easily overlay this configuration on your resources.

• And many more… - Each environment is different, and there are likely countless other times when you may want to use Helm and Kustomize together. Know and understand your requirements prior to making your initial technical decisions.

Two main (mutually exclusive) ways to use them together are:

helm template generates the manifest and dumps it into a file, and then you run kubectl kustomize. The downside is that Helm doesn’t manage any release.

helm install (or helm upgrade --install) and specifying a custom post-renderer that runs kubectl kustomize. The benefit is that Helm manages the release and its full lifecycle.