Photo by Elliot Parker on Unsplash
Helm: Learn how Helm simplifies the deployment of third-party and custom apps
One tool for effectively managing Kubernetes applications is Helm, a package manager for Kubernetes. Helm makes it easier to install apps on your Kubernetes cluster, much like yum/apt makes it easier to install software on Linux distributions.
Helm's usefulness is increased by providing the ability to acquire, implement, and manage the lifecycle of applications, including both third-party products and custom solutions. In the process, Helm presents several widely known ideas:
Charts: These are the Helm packages, similar to the well-known Linux deb/rpm packages.
Helm Repositories: These archives store Charts and work similarly to conventional package archives.
command-line interface (CLI): Commands for installation, updating, and removal are all available
The rationale behind utilizing Helm?
Kubernetes administration can become quite intricate when managing various objects, including ConfigMaps, Secrets, pods, services, and more. Helm takes the responsibility of handling all these components, simplifying the entire process.
With Helm, the creation, management, and deployment of applications through Helm Charts become notably streamlined. Additionally, Helm maintains a versioned history of every chart installation (application). Should any issues arise, the straightforward "helm rollback" command provides a quick solution.
Furthermore, upgrading a chart is necessary, Helm offers the simplicity of a "helm upgrade" command. Deploying applications on Kubernetes, a robust container orchestration system, often involves creating a multitude of interdependent Kubernetes resources, such as pods, services, deployments, and replicasets. This often entails the meticulous authoring of detailed YAML manifest files for each component.
What is a Helm Chart?
In Helm, a chart is essentially a structured collection of manifest files contained within a specific directory arrangement. These manifest files describe Kubernetes resources related to a specific application. A chart primarily consists of two integral components: templates and values. These templates and values undergo a process in a template rendering engine, ultimately producing a Kubernetes-compatible manifest.
Helm employs these charts to encapsulate all the necessary Kubernetes components essential for an application's deployment, operation, and scalability. These charts exhibit a striking resemblance to RPM and DEB packages in the Linux world, facilitating the convenient distribution and consumption/installation of applications through different repositories.
Below is the fundamental directory layout of a chart:
Charts/: chart dependencies that are manually managed can be inputted in this directory. However, it's generally more advisable to employ "requirements.yaml" for the dynamic management of dependencies.
templates/: This directory houses template files that are merged with configuration values originating from both values.yaml and command-line input. These templates are then processed into Kubernetes manifests, utilizing the Go programming language's template format.
Chart.yaml: A YAML file containing the chart's name, version, maintainer information, related website, and search terms, among other relevant metadata
values.yaml: A YAML file containing the chart's default configuration values.
The Helm command provides the capability to install a chart either from a locally stored directory or from a version of this directory structure packaged as a .tar.gz
file. Furthermore, these packaged charts can be fetched and installed automatically from chart repositories, often referred to as "repos."
Think of a release as a way to keep an eye on installed apps in a Kubernetes (K8S) cluster. Helm creates a release when it deploys an application.
The "helm ls"
command can be used to manage these releases, and each release has a unique "revision." This update follows Helm's versioning nomenclature. The version number will be raised if a specific release is updated, such as when memory allocation is increased or the image tag is changed in a nginx-ingress release. Additionally, Helm offers the option to roll back to a particular revision as needed.
In addition to acting as the repositories for Helm charts, repositories store and maintain templates and configuration values that are displayed as code and are frequently compressed into .tar.gz
files. One such example is the application of the Nginx ingress Chart, which was formerly kept up to date in the Helm/Charts repository. Nginx has since decided to move its product to its Helm repository. Using the following instructions, you can easily add their repository to Helm and view the most recent official Chart:
$ helm repo add nginx-stable
https://helm.nginx.com/stable
$ helm repo update
After this setup, you can proceed to install the Nginx ingress using Helm as follows:
$ helm install nginxingress nginx-stable/nginx-ingress
$ helm install ---name nginxingress nginx-stable/nginx-ingress
The Nginx ingress Chart can be more easily deployed from the newly added repository with the use of these commands.
In conclusion, Helm and Helm Charts are invaluable tools for the efficient and streamlined management of Kubernetes applications, enhancing deployment, version control, and scalability while simplifying the complex Kubernetes app deployment process.