Introduction to Helm: Kubernetes Package Manager

You've probably deployed a few applications to Kubernetes by hand. You create a Deployment, a Service, maybe an Ingress, and copy-paste configuration snippets until everything works. Then you need to update the application, so you modify the YAML files, run kubectl apply, and hope nothing breaks. If you have multiple environments—development, staging, production—you're repeating this process for each one. If you need to deploy the same application to a different cluster, you're copying files again. This is where Helm comes in.

Helm is the package manager for Kubernetes. It lets you define, install, and upgrade applications as reusable packages called charts. A chart is a collection of files that describe a related set of Kubernetes resources. Think of it like a Docker image for Kubernetes applications: you pull a chart, deploy it, and it handles all the underlying resources. This article explains what Helm is, how it works, and why you should use it in your Kubernetes deployments.

What is a Helm Chart?

A Helm chart is a collection of files that describe a related set of Kubernetes resources. It includes templates for Deployments, Services, ConfigMaps, Secrets, and any other resources your application needs. The chart also contains metadata like the application name, version, and description. When you install a chart, Helm renders the templates using Go templates and sends the resulting Kubernetes manifests to your cluster.

Charts are versioned, just like software packages. Each version has a semantic version number (e.g., 1.2.3) and can include release notes. This makes it easy to track which version of your application is running in production and to roll back if something goes wrong. Charts can be stored in a chart repository, which is like a package index for Helm. You can pull charts from public repositories like the official Helm chart repository or host your own private repository.

Helm Architecture: Client, Server, and Repository

Helm has a client-server architecture. The Helm client (helm) is a command-line tool that you run on your local machine. It communicates with the Helm server (Tiller) in your Kubernetes cluster. Tiller is a small server that runs inside the cluster and manages releases. When you run helm install, the client sends the chart and release name to Tiller, which creates the release in the cluster.

In recent Helm versions (3.0+), Tiller has been removed. The client now communicates directly with the Kubernetes API server, which simplifies the architecture and reduces security concerns. This means you don't need to install Tiller in your cluster, and you can run Helm entirely from your local machine. The chart repository is still a separate component—it's just a web server that serves chart packages and index files.

Chart Structure and Components

A Helm chart has a specific directory structure. The root directory contains the chart's metadata in a Chart.yaml file. This file includes the chart name, version, description, and dependencies. Below the root, you have subdirectories for templates, which contain the Kubernetes resource manifests. The templates directory can include standard Kubernetes files like deployment.yaml, service.yaml, and ingress.yaml, as well as special files like _helpers.tpl for reusable template functions.

The values.yaml file defines default values for the chart's parameters. These values are used in the templates to customize the deployment. For example, you might have a replicaCount parameter that controls how many replicas of your application to deploy. You can override these values when installing the chart, either via the command line or a separate values.yaml file. This separation of configuration from templates makes charts flexible and reusable across different environments.

Installing and Using Helm

Installing Helm is straightforward. On Linux, you can download the binary from the Helm GitHub releases page and add it to your PATH. On macOS, you can use Homebrew: brew install helm. On Windows, you can use Chocolatey or Scoop. Once installed, verify the installation with helm version. You should see the Helm client version and, if Tiller is still in use, the Tiller server version.

To get started with Helm, you need a chart. You can search for charts in the official repository using helm search repo. For example, helm search repo stable lists all charts in the stable repository. Once you find a chart you want to use, you can install it with helm install my-release stable/nginx-ingress. This command installs the nginx-ingress chart from the stable repository and names the release my-release. Helm creates all the necessary Kubernetes resources and prints the status of the release.

Chart Dependencies and Subcharts

Many applications depend on other components. For example, a web application might need a database, a cache, and a message broker. Helm supports chart dependencies through the dependencies section in Chart.yaml. You can list the charts your chart depends on and specify version constraints. When you install your chart, Helm automatically installs the dependencies in the correct order.

Dependencies can also be subcharts, which are charts stored within your chart's charts directory. This is useful for packaging related components together. For example, you might have a chart for a microservices application that includes subcharts for each service. When you install the parent chart, Helm installs all the subcharts automatically. This makes it easy to deploy complex applications with multiple interdependent components.

Upgrading and Rolling Back Releases

One of Helm's most powerful features is the ability to upgrade and roll back releases. When you need to update your application, you can run helm upgrade my-release stable/nginx-ingress --set image.tag=v1.2.3. This command applies the new version of the chart to the existing release. Helm uses a rolling update strategy, so it gradually replaces the old pods with new ones, minimizing downtime.

If something goes wrong after an upgrade, you can roll back to a previous version with helm rollback my-release 2. This command restores the release to the state it was in after the second upgrade. Helm keeps a history of all releases, so you can easily revert to any previous state. This makes it much safer to experiment with updates and deployments.

Customizing Charts with Values

Charts are designed to be configurable. The values.yaml file defines default values, but you can override them when installing the chart. For example, to change the number of replicas, you can run helm install my-release stable/nginx-ingress --set replicaCount=3. This overrides the default replicaCount value in the chart's values.yaml file.

You can also use a separate values.yaml file with the -f flag: helm install my-release stable/nginx-ingress -f custom-values.yaml. This is useful for environment-specific configurations. For example, you might have values.dev.yaml for development and values.prod.yaml for production. This separation makes it easy to manage different configurations for different environments without modifying the chart itself.

Creating Your First Chart

Creating a chart from scratch is a great way to learn how Helm works. You can use the helm create command to generate a basic chart structure: helm create my-chart. This creates a directory called my-chart with all the necessary files and subdirectories. You can then customize the templates and values to match your application's needs.

The generated chart includes templates for Deployments, Services, and ConfigMaps. You can modify these templates to match your application's requirements. For example, you might change the image name and tag in the Deployment template, or add environment variables in the ConfigMap template. Once you're happy with your chart, you can package it with helm package my-chart, which creates a .tgz file containing your chart. You can then upload this file to a chart repository or share it with your team.

Comparison: Helm vs Manual Kubernetes Deployments

Practical Walkthrough: Deploying a Web Application with Helm

Let's walk through deploying a simple web application using Helm. We'll use the official stable/wordpress chart, which deploys a WordPress site with a MySQL database. First, create a new namespace for your release: kubectl create namespace wordpress. Then, install the chart with custom values for the database password and service type:

helm install my-wordpress stable/wordpress \
  --namespace wordpress \
  --set mysql.password=secretpassword \
  --set service.type=LoadBalancer

This command installs the WordPress chart in the wordpress namespace, sets the MySQL password to secretpassword, and configures the service to use a LoadBalancer. Helm creates all the necessary resources, including the WordPress deployment, MySQL deployment, and a LoadBalancer service. You can check the status of the release with helm status my-wordpress. To view the pods, run kubectl get pods -n wordpress.

Once the pods are running, you can find the external IP of the LoadBalancer service with kubectl get svc -n wordpress. This IP is the URL where you can access your WordPress site. To upgrade the release to a new version, run helm upgrade my-wordpress stable/wordpress --set image.tag=5.9. Helm will update the WordPress image to version 5.9 while keeping the MySQL database intact. If you need to roll back, simply run helm rollback my-wordpress 1.

Best Practices for Using Helm

When using Helm, follow these best practices to keep your charts and releases manageable:

1. Use semantic versioning for your charts. This makes it easy to track versions and dependencies.

2. Separate configuration from templates. Use values.yaml files for environment-specific settings, and keep the templates focused on Kubernetes resource definitions.

3. Test your charts before deploying to production. Use helm template to render the manifests without applying them, and review the output.

4. Use namespaces to isolate releases. This prevents conflicts between different applications and makes it easier to manage permissions.

5. Document your charts. Include a README.md in your chart directory that explains how to install, configure, and upgrade the chart.

6. Use helm lint to check for common issues in your chart before packaging it.

7. Keep charts simple. Avoid over-engineering with complex templates and too many parameters. A simple, well-documented chart is better than a complex, unmaintainable one.

Conclusion

Helm transforms Kubernetes from a manual deployment platform into a package management system. By defining applications as reusable charts, you can standardize deployments, simplify upgrades, and roll back changes with confidence. The separation of configuration from templates makes charts flexible and environment-agnostic, while built-in versioning and rollback capabilities reduce the risk of breaking changes.

The most important thing to remember is that Helm is a tool for managing Kubernetes resources, not a replacement for understanding Kubernetes itself. You still need to know how Kubernetes works to create effective charts. But once you're comfortable with the basics, Helm will save you countless hours of repetitive YAML management and make your deployments more reliable and maintainable.

If you're using a platform like ServerlessBase, you can leverage Helm charts to deploy applications with a few clicks, handling the complex Kubernetes configuration automatically. This lets you focus on building your application while the platform handles the infrastructure details.

Next Steps

Now that you understand the basics of Helm, try creating your own chart for a simple application. Start with a basic web server like Nginx, and customize the replicas, image tag, and service type. Once you're comfortable, explore the official Helm chart repository and install some pre-built charts to see how they're structured. Finally, consider contributing your own charts to the community or hosting a private chart repository for your organization.