What Is Kubernetes Helm?
Package management is not a new concept. In Linux, package managers like YUM, RPM, or APT are essential for installing and removing packages. Node.js developers rely heavily on NPM, the Node Package Manager (NPM), which has thousands of packages that can do virtually anything in a Node.js environment.
As the Kubernetes platform and ecosystem continues to evolve, deploying a single Kubernetes configuration file (i.e. a single YAML) is no longer the norm. Many Kubernetes users have multiple clusters and a large number of resources that need to be coordinated. As the amount of YAML files increases, the question becomes where to store this YAML and how to deploy it conveniently. Helm can help, by packaging multiple YAML files together and deploying them as a single unit.
This is part of a series of articles about Kubernetes architecture.
Why Use Helm?
Helm enables you to automate YAML manifests for Kubernetes objects, packaging information into charts and deploying to a Kubernetes cluster. It tracks the versioned history of each chart installation and change, allowing you to use comprehensible commands to roll back to a previous version or upgrade to a newer one. It also makes it easy to install popular applications to Kubernetes via community-shared Helm charts.
You can leverage Helm to more easily deploy and test an environment, increasing productivity and reducing the time it takes to transition from testing to production. Additionally, Helm can help you simplify and automate the process of sending applications to end users for installation.
Helm Architecture and Components
Here are the three core Helm architecture components:
- Charts—these Helm packages contain all resource definitions required to run an application, service, or tool in a Kubernetes cluster.
- Repositories—allow collecting and sharing charts.
- Releases—instances of charts running within a Kubernetes cluster. You can install one chart many times in the same cluster. Each time a chart is installed, Helm creates a new release.
Helm is an executable implemented into the two main parts:
- The Helm client—a command-line client for end users responsible for managing releases and repositories, interfacing with the Helm library, and local chart development.
- The Helm library—provides logic for executing Helm operations. It interfaces with the Kubernetes API server to install charts into Kubernetes and provide the resulting release object. It also interacts with Kubernetes to upgrade and uninstall charts.
Helm vs. Kubernetes Operators
At a high level, Helm charts and Kubernetes operators do almost the same thing, but adoption varies based on different criteria such as cluster adoption, team maturity, and application requirements.
How are Helm charts used?
For teams that are just starting to run Kubernetes clusters and want to provide simple applications to their users, packaging these applications with Helm charts has the advantage of simplifying template YAML manifests. Helm charts enable IT operations teams to quickly deliver applications by packaging, versioning, and sharing them, together with their dependencies.
To create Helm charts, you need to be familiar with YAML and use the Go templating engine and the Sprig template library.
Helm charts are often most useful when first setting up a Kubernetes cluster to deploy a simple application. They can handle the full life cycle of installing, updating, and uninstalling applications deployed on a cluster.
How are Operators used?
As your team and your use of Kubernetes clusters mature, you may be facing day-to-day tasks and complex requirements to run your applications. This is where the IT operations team needs to add Kubernetes operators to the mix. Writing Kubernetes operators also means the team needs to maintain this code base over time.
Operators are useful for teams implementing complex custom configurations or deploying specialized applications that require significant operational expertise.
Quick Tutorial: Getting Started with Kubernetes Helm
To install Helm on your local machine, you will need to download the Helm binary and add it to your PATH. The easiest way to do this is to use the Helm installer script:
- Download the Helm installer script:
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
- Make the script executable:
chmod +x get_helm.sh
- Run the script to install Helm:
./get_helm.sh
This will install Helm and add it to your PATH. You can then use the helm command to interact with your cluster.
To install a chart using Helm, you will first need to add a chart repository. A chart repository is a collection of charts that you can install from. You can add the official Helm chart repository by running:
helm repo add chartmuseum http://localhost:8080
This will add the “stable” chart repository to your list of repositories. You can then search for charts in this repository by running:
helm search repo stable
This will list all the available charts in the stable repository. To install a chart, use the helm install command and specify the name of the chart and the release name (a unique name for this instance of the chart):
helm install myrelease stable/mysql
This will install the MySQL chart and create an instance of the application called “myrelease”. Helm will take care of creating all the necessary Kubernetes resources and deploying the application on your cluster.
You can also install a chart from a local directory by using the helm install command and specifying the path to the chart directory:
helm install chartmuseum/mychart --generate-name
This will install the chart from the local directory and create an instance of the application called myrelease.
Limitations of Helm Charts
Like any new tool, Helm has a learning curve. Creating and deploying your first Helm chart isn’t easy. Charts also create additional code that needs to be managed and handled. This includes the overhead of managing, maintaining, and storing Helm chart repositories. For simple deployments, Helm might be overkill.
It is, of course, possible to use Helm charts maintained by others. But you need to be sure these Helm charts are well tested and contain only safe components, with no security vulnerabilities.
Keep in mind that applications using many Kubernetes resources can be difficult to troubleshoot using Helm, because you have reduced visibility over individual components.
5 Kubernetes Helm Best Practices
Understand the Template Functions
Helm shapes resource files using Go templates. Go provides several built-in functions, but you can add others. For example, you can add the functions from the Sprig library (although you should avoid expandenv and except env for security reasons. Other useful functions are required and include, which lets you import another template and forward the results to another template function.
For instance, the following template snippet uses the include function to bring in the extpl template, convert the result to uppercase, and wrap it in double quotations.
value: {{ include "extpl" . | upper | quote }}
You can use the required function to declare specific value entries needed to render the template. The template rendering fails if the value is empty.
For example, the following required function provides an entry for the .Values.who element and prints an error message if the required entry is missing:
value: {{ required "A valid .Values.who entry required!" .Values.who }}
Ensure the Types Are Clear
YAML has type coercion rules that can be counterintuitive. For instance, there is a difference between foo: false and foo: "false". In some cases, large integers are converted to scientific notations.
The easiest way to prevent type conversion errors is to make strings explicit while other elements remain implicit—i.e., quoting every string.
It is often useful to store integers as strings to avoid integer casting problems—use the {{ int $value }} element in the template to convert strings back to integers. Usually, the system will respect explicit type tags, i.e., foo: !!string 3287 treats 3287 as a string. However, the YAML parser will consume the tag, meaning you lose the type data after a single parse.
Locate Resources Easily with Labels
Labels are important for the internal operations of Kubernetes—almost all Kubernetes resources offer labels for specific purposes like grouping, load balancing, resource allocation, and scheduling.
You can use one Helm command to install several resources, but you need to know where each resource originates. Labels allow you to find the resources created by a Helm release quickly.
The most common way to define labels is in the helpers.tpl element:
{{/*
My labels
*/}}
{{- define "my.labels" -}}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}
You must then use the include function for labels in each resource template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-queue
labels:
{{ include "my.labels" . | indent 4 }}
Now, you can list all the resources using label selectors. For instance, you can use the following command to list all the pods in the my-queue deployment:
kubectl get pods -l app.kubernetes.io/instance=[Helm Release]
This step allows you to locate and debug the Helm-managed resources.
Keep Secrets Secure
Kubernetes stores sensitive data like passwords and keys as secrets. While you can secure secrets on Kubernetes’ side, storing them as text files in Helm templates and values is more common.
The helm-secrets plugin can manage and protect secrets and critical data. Mozilla SOPS will handle the secret encryption, supporting AWS KMS, PGP, Cloud KMS on GCP, and Azure
The helm-secrets plugin can be installed using the following command:
helm plugin install https://github.com/jkroepke/helm-secrets
Or a specific version
helm plugin install https://github.com/jkroepke/helm-secrets --version v4.1.1
Key Vault.
Suppose you put all sensitive data in a file called secrets.yaml:
postgresql: postgresqlUsername: postgres postgresqlPassword: ZoWpBAlCsg postgresqlDatabase: wp
You can use the plugin to encrypt your file:
$ helm secrets enc secrets.yaml Encrypting secrets.yaml Encrypted secrets.yaml
It will then update and encrypt all the values:
postgresql: postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\] postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\] postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\] sops: ...
The data in the YAML above wasn’t secure, but the helm-secrets element allows you to store sensitive information in Helm charts.
Use Commands to Debug Helm Charts
Helm template files offer many functions and sources of values to create Kubernetes resources. Users must know what resources are deployed to their cluster. Thus, you should learn how to verify Helm charts and debug templates.
You can use these four key commands for debugging:
- helm lint—the linter tool will conduct several tests to ensure the chart is properly formed.
- helm install –dry-run –debug—this function performs template rendering to show the resource manifests. You can check all resources before deploying them to ensure the correct values are set and the template functions work as intended.
- helm get manifest—this command will retrieve the manifests of any resources installed in the cluster. It is the first command you should use if the release does not work as expected, as it shows you what is running in your cluster.
- helm get values—this command retrieves the values of releases installed in the cluster. It is useful if you are unsure about any default or computed values.
See Additional Guides on Key Kubernetes Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Kubernetes.
Kubernetes Troubleshooting
Authored by Komodor
- Kubernetes CrashLoopBackOff Error: What It Is and How to Fix It
- Kubernetes Health Checks: Everything You Need to Know
- How to Fix CreateContainerError & CreateContainerConfigError
Kubernetes Lens
Authored by Komodor
Kubernetes Performance
Authored by Granulate
