Helm Guide: An Introduction to the Kubernetes Package Manager

Helm has become an essential part of the Kubernetes ecosystem. By using Helm, one can simplify the process of creating and deploying Kubernetes resources. In this article, we walk through the basic components of Helm, its architecture, and the benefits of using Helm. Then we have a tutorial on deploying Helm charts using Argonaut.

What is Helm?

Helm is a package manager for Kubernetes that simplifies application deployment and management. It enables users to define, install, and upgrade complex applications with a single command. Helm offers a user-friendly design suitable for beginners and experts and a vast library of ready-to-use charts for effortless installation and management of diverse applications.

Key concepts in Helm

Helm manages the deployment lifecycle of applications using Helm Charts, which ensures consistency across different environments and users. Users can create their own Helm charts for deployment or utilize charts for third-party and open-source tools from public repositories, such as artifacthub, bitnami charts, harbor, and chart museum.

Helm chart

A Helm chart is a collection of files describing the resources and dependencies needed to deploy an application on Kubernetes. It allows for modularization and versioning, making application distribution, sharing, and management more accessible across various clusters and users.

The package consists of multiple files and directories, each with a specific function. Helm reads the chart and generates the necessary Kubernetes manifests based on the provided configurations (values.yaml file).

Helm charts can have dependencies, called subcharts which are stored in the charts/ directory.

Structure of a Helm chart

Helm releases

The next important component in the Helm architecture are releases. Releases in Helm represent the instances of a deployed Chart within a Kubernetes cluster. A release constitutes of all the Kubernetes objects and resources, such as deployments, services, and ingress rules, which are created as part of the specified configuration in the chart.

Helm chart repository

Helm chart repositories, or repos, are dedicated HTTP servers that host and serve charts alongside an index.yaml file, which provides information about a collection of charts and their download locations.
A Helm client can connect to multiple chart repositories, initially configured with none by default. Using the helm repo add command, users can effortlessly configure and add new chart repositories, enabling seamless access to and management of various charts for their Kubernetes deployments.

Popular chart repositories are artifcathub, bitnami charts, harbor, and chart museum.

Chart version

Every chart must have a version number. Packages in repositories are identified by name plus version. Helm charts are versioned according to the SemVer2 spec. For example, an nginx chart whose version field is set to version: 1.2.3 will be named: nginx-1.2.3.tgz

The version number is found in the Chart.yaml file and is used by various Helm tools, including the CLI. When creating a package, the helm package command uses the version number from the Chart.yaml in the package name. The system expects the version number in the chart package name to match the one in the Chart.yaml, and any discrepancy will cause an error.

Chart dependency

In Helm, one chart may depend on any number of other charts. These dependencies can be added in two ways - by dynamically linking using the dependencies field in Chart.yaml or by bringing it into the charts/ directory and managing manually.

Example using dependencies field:

dependencies:
  - name: apache
    version: 1.2.3
    repository: https://example.com/charts
  - name: mysql
    version: 3.2.1
    repository: https://another.example.com/charts

Example using charts/ :

wordpress:
  Chart.yaml
  # ...
  charts/
    apache/
      Chart.yaml
      # ...
    mysql/
      Chart.yaml
      # ...

Release number (release version)

A release can be modified several times. To keep track of these changes, a continuous counter is utilized. Upon the initial helm install, the release number is set to 1. With each subsequent upgrade or rollback, the release number increases by 1. This history is useful if one needs to roll back to a previous release number.****

Helm Rollbacks

The helm rollback <RELEASE> [REVISION] [flags] command can be used to roll back to any previous version of the release. Note: a rolled back release will receive a new release number. You can find a list of flags here.

Helm library (or SDK)

The Helm Library (or SDK) refers to the Go code that interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It can be imported into a project to use Helm as a client library instead of a CLI.

This is an advanced technique released in Helm 3. You can check the official docs here. And examples here.

Helm architecture

This diagram better explains how Helm uses charts and value files to manage releases (deployed resources) in your Kubernetes cluster.

This diagram shows the OpenTelemetry Operator Helm chart workflow. Here you see how the AWS Observability team builds and maintains the Helm chart in a public repo, and it can be seamlessly downloaded and deployed to users’ clusters.

This process also has several benefits compared to the previous methods of deploying an OpenTelemetry operator.

• Added functionality such as installing/uninstalling packages, upgrades, rollbacks, and customized installations.
• User flexibility to configure values through the values.yaml file, you determine which values to pass to the OpenTelemetry Operator Helm chart configuration. You can override multiple values with one command.
• It’s the easiest way to deploy the Operator to Kubernetes.

For more information, check out this AWS blog.

Why you should use Helm?

There are several ways to deploy and manage resources on Kubernetes; why should you choose Helm? Popular alternatives are Kustomize, Tanka, and Carvel, all of which have less mature communities than Helm and lack the number of publicly available charts (packages).

Helm has emerged as the clear winner with its ability to handle both simple and complex configurations, versioning, reusability, etc.

There are also ways to use Helm and Kustomize together.

Here are the key benefits of Helm:

• Simplicity: Defining, installing, upgrading, and rolling back complex Kubernetes applications can be done with a single command. This greatly simplifies the management and deployment of Kubernetes resources.
• Reusability: Helm charts are essentially packages of pre-configured Kubernetes resources. The charts can be reused across projects and shared with the wider community.
• Configurability: Helm provides a highly configurable structure with Charts(templates) and values(configs). Just by changing a few parameters, we can use the same chart for deploying on multiple environments like stag/prod or multiple cloud providers.
• Consistency: Helm charts provide a standardized way of packaging and deploying Kubernetes resources. This can help ensure consistency across different environments and reduce the risk of errors or inconsistencies in deployment.
• Scalability: With Helm, you can easily scale your Kubernetes applications up or down by adjusting the values in the values.yaml file.
• Community: Helm has a large and active community that is constantly developing and improving the tool. This means that there are many resources and best practices available to help you get the most out of Helm.

Tutorial - Deploy Helm charts using Argonaut

Here’s a quick demo of deploying a Helm chart of OSS and third-party tools to your Kubernetes cluster using Argonaut. Argonaut’s platform helps you simplify cloud deployments and infra management. You can choose any publicly available Helm chart and deploy it to your Kubernetes cluster on AWS and GCP cloud.

The beauty of using Argonaut is that you don’t need to use any Helm commands. You can set the chart configs, version, and edit values.yaml using our simple UI. Your Kubernetes resources are then deployed using GitOps best practices using ArgoCD under the hood. Also, when you create a cluster using Argonaut, we automatically add essential apps such as Keda, Kubernetes events exporter, Nginx-Ingress, Cert-manager, Prometheus, and metrics-server.

In this example, we will be deploying rabbitmq.

Pre-requisites

1. Argonaut account
2. AWS/GCP account connected to Argonaut
3. A k8s cluster created using/imported to Argonaut

Deploying Helm chart

1. Select your environment from the Argonaut dashboard
2. In your selected cluster, click on the Add-ons button to see the pre-installed apps
3. Click on Application +
4. Choose From Library
5. Ensure your environment and cluster names are correct
6. Select the Custom-Apps option
   1. Use the default tools namespace
   2. Set release name as my-rabbitmq
   3. Set chart name as rabbitmq
   4. Repo URL as https://charts.bitnami.com/bitnami
   5. The latest chart version will be automatically fetched; you can change to an older version if needed
   6. Click on load values.yaml to see the values file
   7. You can modify as needed and add overrides or annotations
7. Click Install. Rabbitmq is now added to your cluster!

It’s just as simple to install all other apps using Helm charts. Just ensure the chart name is the same as the one in the repo. And to find the correct Helm repo URLs for your apps, you can search https://artifacthub.io/.

💡 If you want to try installing it using Helm CLI commands, here is a useful tutorial.

Conclusion

Helm has proven to be an invaluable tool for managing Kubernetes applications. With its powerful features, such as simplicity, reusability, configurability, consistency, and scalability, Helm enables users to harness the full potential of Kubernetes without a steep learning curve. Additionally, the active and growing community behind Helm ensures that it will continue to improve and remain the go-to solution for deploying and managing complex Kubernetes resources.

By using tools like Argonaut alongside Helm charts, you can simplify your cloud deployments even further and streamline your infrastructure management processes. As demonstrated in our tutorial on deploying RabbitMQ with Argonaut.

Ultimately, if you're looking to deploy and manage Kubernetes applications efficiently while minimizing errors and inconsistencies in deployment processes, consider adopting Helm as your go-to package manager.

References for this article:

1. https://helm.sh/docs/glossary/
2. https://circleci.com/blog/what-is-helm
3. https://trstringer.com/helm-kustomize/
4. https://aws.amazon.com/blogs/opensource/building-a-helm-chart-for-deploying-the-opentelemetry-operator/
5. https://helm.sh/docs/intro/quickstart/