Helm charts: A comprehensive guide for Kubernetes application deployment

Helm is a package manager for Kubernetes that streamlines how applications are defined and installed on a cluster. It uses charts as a packaging format, a collection of YAML templates and definitions that describe a set of related Kubernetes resources. 

By bundling all the necessary manifests for an application, such as Deployments, Services, and ConfigMaps, into one chart, Helm helps developers deploy complex microservice stacks with one command. This is easier than writing and managing multiple raw YAML files. In essence, a Helm chart acts like an installable blueprint for an application, which ranges from one pod to a web app stack with databases and caches. 

Deploying applications with Helm makes Kubernetes workflows more consistent and repeatable. Like package managers such as apt and yum manage Linux packages, Helm manages Kubernetes deployments with versioned charts. It automates installation and also handles upgrades and rollbacks, making the lifecycle management of Kubernetes applications easier.

Structure of a Helm chart

A Helm chart follows a well-defined directory structure and file format. This structure organizes an application’s Kubernetes manifests and configuration in a reusable way. Components include:

• a metadata file

• default configuration values

• templates for Kubernetes resources

• dependencies on other charts (optional)

Here are more details on these components:

Chart metadata (Chart.yaml)

Every chart has a Chart.yaml file at its root. This YAML file contains metadata about the chart, such as its name, version, a description, and other information like the app version and maintainers. The Chart.yaml defines what the chart is. For example, a chart named “wordpress” might have metadata indicating it is version 1.2.3 and is a web application stack. Helm uses this metadata to identify the chart and manage versioning and dependencies.

Default configuration (values.yaml)

A chart is customized with a values.yaml file, which provides default configuration values. These values define aspects such as image names, replica counts, resource limits, or any tunable setting for the app. 

When you install a chart, you supply your own overrides for these values via a custom values file or command-line parameters to configure the deployment for your environment. The values.yaml acts as the chart’s configuration interface; it lists parameters and default settings that the chart’s templates reference. This separation allows charts to be reused across environments by changing values instead of editing templates. 

Templates and Kubernetes manifests

Kubernetes manifest templates are stored in the templates/directory of a chart. These are typically YAML files, such as Deployment.yaml and Service.yaml, with placeholders and Helm template syntax. Helm combines these templates with values from values.yaml and user-provided overrides to create Kubernetes manifest files upon installation. 

For example, a Deployment template might include a placeholder for an image tag that gets substituted with a value from values.yaml. With templates, one chart adapts to different configurations, and it reduces duplication in your Kubernetes resource definitions.

Helm’s templating engine also supports conditionals and loops, so charts include resources dynamically based on values, such as “create a LoadBalancer Service only if a certain value is enabled.” When you run helm install, Helm takes the template files in the chart, fills in the values, and turns them into the Kubernetes YAML files. Those finished YAML files are then sent to the Kubernetes cluster to create the resources.

Chart dependencies

Helm supports composing applications from smaller components through chart dependencies. A chart declares that it depends on other charts. For example, your web application chart might depend on a database sub-chart. These are defined in the Chart.yaml under a dependencies section and packaged in a charts/ directory. Helm pulls in and installs dependency charts when you install the main chart. This lets you reuse existing charts, such as using a stable MySQL chart as part of your application, rather than reinventing them. 

Dependencies make managing complex stacks easier by breaking them into logical pieces that are installed and managed together. During packaging, Helm bundles dependent charts or fetches them from remote repositories when needed via Helm dependency update. This mechanism encourages a modular design of Kubernetes applications, fostering reuse of community-maintained charts for common services.

Using Helm charts

Use Helm charts in two main ways:

1. With existing charts, perhaps from an open-source repository or vendor, to deploy known applications

2. Create your own charts to package and deploy custom applications

In both cases, Helm provides a consistent workflow for installing, upgrading, and managing application releases on your cluster. Here is how to work with Helm in both scenarios.

Installing applications from existing charts

One of Helm’s strengths is the ecosystem of pre-made charts for popular software. To use an existing Helm chart, start by adding a Helm repository with the chart. Helm Hub (now Artifact Hub) is a central place to find community charts, and many organizations publish charts in their own repositories. 

For example, to use the Aerospike Kubernetes Operator’s chart, add Aerospike’s Helm repo with helm repo add aerospike <repo_url>. Once the repository is added and updated with helm repo update, install the chart by name. The installation process lets you set configuration values at runtime. 

Override defaults by supplying your own values.yaml or using --set flags on the command line for quick tweaks. Helm fetches the chart, templates it with your values, and creates a release, or a deployed instance of the chart in your cluster. The release is given a name and tracks the specific version of the chart and the Kubernetes resources it created. 

Using pre-existing charts in this way lets you deploy complex applications such as databases and monitoring stacks in minutes, with manifests that chart maintainers test and tune. Moreover, because charts are versioned, you can choose a specific chart version known to be stable, and later upgrade to newer versions in a controlled way.

Developing a custom Helm chart

If you are deploying a custom application or want more control, create your own Helm chart. Helm’s CLI has a scaffold command (helm create <chart-name>) that generates a basic chart directory with some default templates and a placeholder values.yaml. From there, define your application’s Kubernetes resources in the templates/ files. 

For instance, define a Deployment for your app’s container and a Service for exposure. Parameterize these manifests with the values.yaml, such as allowing the image tag or replica count to be set via values. Documentation and metadata go into Chart.yaml, including setting an appropriate version for your chart. 

As you develop, use helm install --dry-run --debug to render templates locally so everything is correct. Once ready, packaging your chart is as simple as using helm package, which creates a versioned .tgz archive of your chart. Share this chart archive within your organization or publish it to a Helm repository. 

Many teams maintain internal Helm repositories or use object storage or artifact registries to distribute charts for their applications. A custom chart means your deployment configuration is repeatable and version-controlled; anyone spins up the same app with a Helm install; updates to the app are rolled out by updating the chart and bumping its version. This approach brings the benefits of infrastructure-as-code to your Kubernetes apps, encapsulating required resources and configurations into an easy-to-use package.

Benefits of Helm charts

Helm has quickly become a standard tool in the Kubernetes ecosystem because of the benefits it provides to both developers and operators. By abstracting the complexity of Kubernetes configurations into higher-level charts, Helm makes deploying and managing apps more efficient and reliable. Here are several benefits to using Helm charts:

Simplified application deployment

Helm simplifies deployment by organizing complex Kubernetes manifests into reusable charts. Instead of dealing with dozens of YAML files and manually creating resources in the right order, define everything in a chart and deploy it with one command. This not only saves time but also reduces human error. Charts include hooks to automate tasks such as waiting for services or running database migrations, further smoothing deployments. 

For teams, this means faster and more consistent rollouts of applications or microservices. In practice, using Helm feels like deploying an application as one unit, even if under the hood it consists of many interdependent Kubernetes objects.

Versioning and easy rollbacks

Each installation of a chart is tracked as a release with its own revision history. This built-in versioning is an advantage for ongoing operations. When you upgrade a Helm release, such as deploying a new version of your application, Helm records a new revision. If anything goes wrong, roll back to a previous revision with one command. 

This capability makes updates safer and speeds recovery from failed deployments. While manually rolling back a Kubernetes deployment might involve reapplying a series of old manifests, Helm does it automatically by storing the prior config state. Push changes knowing that if an issue arises, reverting to the last known good state is straightforward. In short, Helm provides a safety net for changes, which is essential for continuous delivery.

Consistent configurations across environments

Helm charts promote consistency by allowing you to reuse the same Kubernetes manifests across multiple environments, such as development, staging, or production, with only small differences captured in the values files. The chart templates remain the same, so the core architecture of your application doesn’t drift between environments. 

You might have a values-dev.yaml with debug settings and a values-prod.yaml with scaling and URLs for production, but both use the same chart templates. This consistency reduces configuration drift and bugs that arise from environment differences. 

Moreover, it supports a GitOps style workflow; store your chart and values in version control and deploy the same way every time. Operations teams appreciate this consistency as it leads to more predictable behavior and easier troubleshooting when issues do occur.

Integration with CI/CD pipelines

Helm fits into continuous integration/continuous delivery (CI/CD) pipelines. Automate deploying a Helm chart via the command line, so it’s easy to plug into build scripts and continuous deployment tools. 

For instance, a CI pipeline might package a new chart version when application code is updated, and a CD system might run helm upgrade to push that change to a staging or production cluster. Helm’s support for rolling back also means your CD pipeline reverts a release if health checks fail, for more sophisticated automated deployments. 

Because charts bundle all Kubernetes objects, treat an application upgrade as one atomic unit in your pipeline. This simplifies continuous delivery, as opposed to applying multiple kubectl commands. 

Companies adopting GitOps also use Helm by storing charts in git and using automation to deploy them, benefiting from code review and version control on their infrastructure changes. In summary, Helm helps teams achieve faster, safer deployments as part of DevOps practices, accelerating delivery without sacrificing control.

Reusable charts and community ecosystem

Helm has a rich ecosystem of community-contributed charts for all kinds of software, including databases, message queues, and CI tools. This means you rarely have to write a chart from scratch for standard components; instead, use charts maintained by the community or vendors. Using official or well-known charts brings in best practices for deploying those applications on Kubernetes, such as setting up proper security contexts or liveness probes, which might be challenging to craft by yourself. 

Additionally, if you develop a chart for your own application, share it within your organization or even publish it for others to promote reuse. This modularity is similar to using libraries in programming; charts let you plug in functionality to your deployments easily. 

The large package ecosystem and the support of the Cloud Native Computing Foundation (CNCF) behind Helm mean it’s continuously improving and well-supported. There’s also a strong community offering support and tools such as Helm plugins, which add functions. This makes less work for teams, because you’re taking advantage of the community’s collective knowledge when you use Helm charts.

Deploying stateful applications with Helm

While Helm is often used for stateless microservices, it also manages stateful applications such as databases and other data stores on Kubernetes. Stateful applications typically require persistent storage and stable network identities, which Kubernetes handles with StatefulSets and PersistentVolumeClaims. Helm charts encapsulate these Kubernetes resources and their configurations, making it straightforward to deploy complex stateful systems. In fact, many official charts exist for popular databases, which demonstrate best practices for running those stateful services on a cluster. 

Helm also works with Kubernetes Operators for stateful apps. An Operator is a custom controller that encodes operational knowledge for managing an application. Some vendors distribute Helm charts that install and configure their Operator, which in turn manages the stateful workload. This setup gives you Helm’s simple installation process, while the Operator handles ongoing, day-to-day management.

A case in point is the Aerospike database: Aerospike provides an official Helm chart to install its Kubernetes Operator (AKO) and deploy Aerospike clusters. Using that chart, spin up a full Aerospike cluster with the proper StatefulSets, volume claims, and configuration in one command. The Helm chart handles the initial setup, and then the Operator takes over so the database cluster stays healthy and scales or recovers. 

Even for sophisticated stateful systems, Helm charts are an integral part of the cloud-native deployment toolkit, abstracting away the intricacies of stateful set configuration. The ability to “helm install” a database cluster means faster provisioning and a standardized approach to infrastructure. Organizations running data-intensive workloads benefit by getting reliable, repeatable deployments for services that traditionally have been considered complex to orchestrate in containers.

Aerospike and Helm charts

Helm charts are useful for managing complex Kubernetes workloads. By packaging applications into self-contained, versioned charts, Helm brings simplicity, consistency, and confidence to deployments. Teams deploy and upgrade services more easily, knowing that Helm handles template rendering, dependency management, and state tracking. This reliability and efficiency make Helm a cornerstone of Kubernetes-based DevOps workflows, especially as applications get bigger and more complex. 

One example of using Helm for streamlined deployment is Aerospike. Aerospike is a real-time NoSQL data platform known for its high performance and ultra-low latency on large datasets. It provides official Helm charts as part of its Kubernetes Operator, allowing users to more easily set up and manage Aerospike clusters on Kubernetes. With Helm charts, deploying Aerospike in cloud or on-premises environments is quick and consistent, so organizations focus on building real-time applications without worrying about underlying infrastructure details.