Introduction
Helm simplifies managing complex Kubernetes environments to streamline CI/CD pipelines and foster reusability across Kubernetes configurations. Helm is a Cloud Native Computing Foundation (CNCF) project created in 2015. Since then, it has become an integral part of the Kubernetes ecosystem and has quickly gained popularity among developers and DevOps engineers. Take a look at this Helm chart tutorial to learn the basics of what you need to get started.
Packagecloud integrates with CI/CD tools such as Jenkins and Travis to automate package distribution. Sign up for the Packagecloud free trial to get set up today.
Why Developers and DevOps Engineers Love Helm Charts?
Helm is a DevOps tool that streamlines installing and managing Kubernetes applications. The tool packages configuration files in a format called charts. A chart describes a related set of Kubernetes resources. Helm is a welcome tool for developers and DevOps engineers responsible for managing Kubernetes clusters. Here’s why.
Traditionally, teams used Kubernetes YAML files to configure and specify everything Kubernetes needed to deploy containers. The file defined, for example, which pod needed to be configured and how to load balance the cluster. Creating a new workload meant manually writing a new YAML file. With Helm, teams don’t need to write separate YAML files. They can create a Helm chart and let the tool deploy the cluster for them.
Helm enables developers to customize app configurations during deployment, allowing them to reuse one Helm Chart across multiple environments. CI/CD pipeline for Kubernetes workloads is simplified because they can streamline the workflow easily. Helm also maintains versioning to accommodate quick rollback in case of issues.
Helm Components and Terminology
Helm has two elements, a client (Helm) and a server (Tiller). The server element runs inside a Kubernetes cluster and manages the installation of charts.
Helm: The Helm command-line interface (CLI) is used to install charts into Kubernetes clusters.
Helm Charts: A chart is a packaged collection of related Kubernetes resources configured and deployed together as a single unit.
Repository: Charts are stored in a Chart Repository, which can be either public or private. Users can search for and download charts that fit their needs.
Release: Represents an instance of a chart running in a Kubernetes cluster. The same chart can be used multiple times to create many releases.
Tiller: Tiller generates Kubernetes resource manifests, which are YAML-formatted files that describe a resource.
Packagecloud provides support for a variety of package management platforms to streamline deploying your packages. Sign up for the Packagecloud free trial to get set up today.
Helm Chart Basics
After installing Helm, you should see the below file structure. This file structure is a high-level view of the files needed to create a Helm chart.
mychart/
Chart.yaml
values.yaml
charts/
templates/
Chart.yaml is a YAML-formatted file that contains the configuration settings for a Helm chart, including values such as package names, version and release type.
Values.yaml is used to store data specific to each environment. It defines parameters like secrets or external services credentials needed by other charts installed on top of this helm chart.
The Charts directory provides a list of all available charts inside your repository.
Templates (Directory) is where existing Kubernetes manifests can leverage the values in Values.yaml.
Chart Lifecycle
To perform an installation from a Helm chart, developers use the Helm CLI. These are the steps that take place to create the specified environment:
- Helm CLI loads the chart into Tiller. Tiller is a daemon that manages the Kubernetes control plane and runs in the master node
- Tiller processes the configuration file and generates a manifest that contains all the required Kubernetes resources:
- The manifest is sent to the Kubernetes API server on the master node.
- The client then accesses the Kubernetes API server and issues a request to create a new Service. This request is passed through Tiller and results in a new Kubernetes object being created:
- The API server returns a new Service object, which uses Helm to install its associated resources.
- The chart's Tiller configuration file is processed and included in the manifest so the chart can be installed successfully
- Helm's client-side code calls the helm install command, which then fetches the manifest from Tiller.
- The Helm CLI then executes the install command on the client-side code.
- Finally, Helm's client-side code calls the helm upgrade command, which fetches and applies the manifest from Tiller.
- Tiller then downloads and installs the charts from the Helm repository. The installation process also includes any package dependencies - these are not downloaded, but are installed along with the chart itself. Helm downloads and installs dependencies to avoid upgrading conflicting packages at runtime.
- The resulting manifest can be used to create Kubernetes resources in Tiller:
- Tiller creates the chart templates.
- Each template creates a Kubernetes manifest file. Tiller runs each of the template files to generate resource files.
- Tiller loads the resources into Kubernetes.
- Tiller returns the release data to the client.
- The client exits.
Helm Best Practices
Helm charts make it easy to manage complex Kubernetes configurations. This convenience can quickly become a hassle if not used properly. Here are a few best practices to help ensure Helm charts continue to provide maximum benefit for your environment.
Default Values: Use Helm to replace a known, fixed set of values. This helps with reproducibility and comparison across clusters or organizations.
Environment Variables: Include environment variables in your helmfile so they can be easily changed during installation without the need for another step at deployment time.
Templates: Create templates for all features, including secret keys and TLS certificates (certificate authorities) which are generated on-demand from different sources, such as registries or CI/CD pipelines; do not hardcode secrets in charts.
Storage Backend: Define a default storage backend for the storage section of your chart.
If you don't specify anything, Helm will use the default storage backend defined in the chart by default. Defining a storage backend is useful when you want to avoid defining a different storage backend for each chart.
Why Packagecloud?
Packagecloud is a cloud-based service for distributing different software packages in a unified, reliable, and scalable way, without owning any infrastructure. You can keep all packages that need to be distributed across your organization's machines in one repo, regardless of OS or programming language.
Sign up for the Packagecloud free trial to easily get your machines set up and updated!
