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.
Helm is a package manager for Kubernetes that 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 simple 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.This is part of a series of articles about Kubernetes architecture.
How Does Helm Work?
Helm operates by defining and managing charts, which are packages of pre-configured Kubernetes resources. When a chart is deployed, Helm communicates with the Kubernetes API to create and manage the defined resources within the cluster. A file called ‘values.yaml’ provides variables needed to correctly deploy specific resources.
[this is a copyrighted image, do not use it as is. We recommend rebuilding with your graphic designer. Change text as follows:
- Container actual resource.. → Information about resources to be deployed
- Contains actual configurations… → Configurations for resources
- Uses values.yaml… -> Deploys resources, using values.yaml to insert missing variables]
What Is a Helm Chart?
A Helm chart is a collection of files that describe a related set of Kubernetes resources. This includes:
- chart.yaml: Contains metadata about the chart, such as its name, version, and description.
- values.yaml: Specifies default configuration values for the chart.
- templates folder: A directory containing the Kubernetes resource templates. These are processed using the values specified in values.yaml to generate the final YAML configuration files.
- charts folder: A directory containing dependencies, which are other charts that this chart relies on.
- README.md: Provides an overview and usage instructions for the chart.
By packaging Kubernetes manifests into a chart, Helm simplifies the deployment and management of applications. Charts can be shared and reused, promoting consistency and reducing duplication of effort.
What Is a Helm Chart Repository?
A Helm chart repository is a collection of Helm charts that are made available for installation. These repositories can be public or private and are often hosted on platforms like GitHub or dedicated Helm repository services.
Repositories are defined by an index.yaml file, which lists the available charts and their versions. Users can add repositories to their Helm client using the helm repo add command and then install charts from these repositories with helm install. Public repositories, such as the Helm stable and Helm incubator repositories, provide access to a wide range of community-maintained charts for popular applications and services.
Helm Architecture and Components
Helm Client
The Helm client is the primary user interface for Helm. It provides the command-line interface (CLI) used to execute Helm commands, such as installing, upgrading, or rolling back charts. The Helm client interacts with the Helm library to process charts and manage releases. It also communicates with the Kubernetes API server to deploy and manage resources in the cluster.
Helm Library
The Helm library contains the core logic for Helm. It handles the rendering of templates, the management of releases, and the communication with the Kubernetes API. The Helm library is responsible for the following tasks:
- Rendering templates: It processes the templates in the chart using the values provided in values.yaml to generate the final Kubernetes manifests.
- Managing releases: It tracks the state of each deployment, allowing users to upgrade, roll back, or uninstall charts while maintaining versioned history.
- Interfacing with Kubernetes: It sends the generated manifests to the Kubernetes API server to create or update resources in the cluster.
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
