Explain the Kubernetes package management tool Helm

Author | Ray Elenteny

Translated by | Winter rain

Planning | Chu Xingjuan

When mentioning Helm, we often make the analogy that Helm is to Kubernetes as apt is to Debian-based systems, and yum or rpm is to Red Hat-based systems. In addition to package management, Helm has much of the content built into configuration management.

Helm is a package management tool for Kubernetes, originally developed by a company called Deis, and later acquired by Microsoft. Microsoft has sped up its development with full support for Helm, which is now part of the Cloud Local Computing Foundation (CNCF).

Image credit: "Helm history" – A demonstration slide of the Helm project at CNCF TOC in May 2018

As part of the CNCF, Helm has been actively developed and supported by numerous organizations, resulting in a large and active community. Here's an example of Helm's project contribution statistics as of October 2021:

Table Source: China National Petroleum Fund Development Statistics Project "Project Overall Statistical Table"

1

Why does Kubernetes need a package manager?

Most technologies introduce key concepts with the example of "Hello World," and Kubernetes is no exception. Deploying any component to a Kubernetes cluster, with the exception of the simplest, requires coordination across multiple components.

For example, the process of managing application deployments outside a Kubernetes cluster is not complicated, but it becomes a tedious task due to dependencies and dependencies on versions, configuration artifacts, pre- and post-deployment steps, validation, and so on. Just as apt and yum manage the process for Linux, Helm handles the process for Kubernetes.

In general, the Helm feature has the following characteristics:

Kubernetes manages the deployment lifecycle of components and applications

Template-based definitions that support portability across deployment environments (for example, development, warranty, production).

The hook mechanism can inject use case-specific code at different stages of the deployment lifecycle

Deploy the test framework

2

Structure of Helm

To use Helm, you only need to install one executable. The helm command provides more than 20 parameters for building, deploying, deleting, rolling back, and so on, deploying applications into a Kubernetes cluster.

The Helm deployment artifact is the Helm Chart. The Helm Chart consists of resources for deploying a component or application to a Kubernetes cluster. The most common resource in Chart is a YAML file, which follows the standard Kubernetes resource description. If you're proficient at deploying to a Kubernetes cluster using the kubectl create or kubectl apply commands, you'll find the YAML files in Helm Chart look familiar. Helm Charts typically contain additional resources, such as README files, default parameter files, and additional files (such as certificates) that are required for deployment.

Developing Helm Chart requires organizing files using a predefined directory structure. You can use the Helm command helm create to create a Helm chart, which is a predefined directory structure that contains some sample files. The resulting chart contains several YAML files. A Kubernetes deployment typically requires multiple Kubernetes resource descriptions to deploy, and in many cases, these deployments must have a priority order. When deploying manually, you must know the order. Helm doesn't have to, because Helm knows the prioritization of Kubernetes resource descriptions.

A key feature of the Helm deployment process is Chart Hooks. During the deployment lifecycle of Helm Chart, the Chart hook is a mechanism for performing additional tasks. Helm supports the following points to introduce graph Chart Hooks:

Source of the table: "Useful Hooks – Chart Hook", Helm Chart can rely on other Helm Charts

For example, an application might contain a dependency on a set of microservices defined by its own Helm Chart. When the application is deployed, Helm manages these dependencies. To be consistent with the microservices pattern, each component can be updated independently of the others, so it remains the definition of a collection of cohesive applications.

3

Plan your Helm deployment

Helm has a role to play in all aspects of application development and deployment, which requires engineering and operations teams to work closely together to design solutions and answer deployment questions. With team coordination, deployment decisions can be made iteratively to support the goals of each environment with a single deployment package to accommodate the differences in each deployment environment.

In addition to the hook concept described earlier, Helm provides a robust template mechanism that enables teams to solve the challenge of a single deployment package. In general, the YAML file in the Helm Chart does not look like a handwritten YAML Kubernetes resource description.

Instead, the YAML files in Helm Chart were developed using Helm's templating language:

This templated ingress description example generated by helm create provides several variables for defining and configuring ingress resources, including whether or not ingress resources should be created. Through templates, Helm provides a lot of control over how Kubernetes resources are deployed. A well-planned template pattern generates a single deployment package that enables Successful Deployment of Helm Chart, ranging from a single-node Kubernetes cluster on a developer workstation to a production Kubernetes cluster.

4

Helm Chart 和 CI/CD

As part of an organization's continuous integration/continuous delivery pipeline, Helm plays the role of facilitator and component. As an enabler, it enhances the pipeline by being a mechanism for deploying applications or components across environments (engineering, warranty, delivery, certification, production, and so on). In a CI/CD pipeline, automated Helm Chart deployment is straightforward.

As an application component, Helm Chart is also iteratively developed and deployed like application code. This means that the CI/CD pipeline is indispensable when validating the Helm Chart itself. In fact, the Helm Chart should be considered part of the application code, not the peripheral part of the application development process—and even the Helm Chart should be managed as part of the application's source code. Similar to how an application builds a versioned container image and pushes it to an image registry, the helm package binds the chart to a versioned archive. The resulting archive is committed to the Helm Chart repository, from which it can be accessed for deployment.

The diagram above highlights the stages in the application software development lifecycle. Whichever mode you use to manage the source code of the Helm Chart, it is as indispensable in the application CI/CD pipeline as the application itself.

5

Conclusion

Helm has always been part of the Kubernetes ecosystem hype curve, and as the Kubernetes hype curve begins to flatten, Helm has matured. Was Helm's approach revolutionary? Not exactly. Helm has built up a wealth of software packages and configuration management tools over the years and now brings that experience to Kubernetes. At the same time, Helm's view of defining deployment packages through the Helm Chart has a direct impact on the efficiency of an organization's CI/CD pipeline, most notably configuration patterns and deployment flexibility. A well-designed Helm Chart is an important part of effective delivery.

https://dzone.com/articles/kubernetes-package-management-with-helm?