Kubernetes Package Management With Helm

This is an article from DZone's 2021 Kubernetes and the Enterprise Trend Report.

For more:

Read the Report

Introducing Helm

Helm is a package manager for Kubernetes. Given a running Kubernetes cluster of any type, Helm is used to manage the deployment lifecycle of just about any type of Kubernetes resource, including the management of many Kubernetes runtime components. A very common analogy used in describing Helm is that Helm is to Kubernetes as apt is to Debian-based systems and yum or rpm is to Red Hat-based systems. Beyond package management, many aspects of configuration management are also built into Helm. Helm was initially developed by a company named Deis, which was acquired by Microsoft. Microsoft fully supported and accelerated the development of Helm, and it is now a part of the Cloud Native Computing Foundation (CNCF). 

As part of the CNCF, Helm is actively developed and supported by numerous organizations, and it has since developed a large and active community. The following is a sample of Helm project contribution statistics as of October 2021:

Table source: "Overall Project Statistics Table," Helm DevStats Project of the CNCF

Why a Package Manager for Kubernetes?

Like most technologies, "Hello World" examples introduce key concepts, and Kubernetes is no exception. Deploying anything beyond the most straightforward component to a Kubernetes cluster requires coordination across multiple components. For example, the process for managing application deployment outside a Kubernetes cluster is not complex. However, it is tedious since there are dependencies and dependency versions, configuration artifacts, pre- and post-deployment steps, validation, etc. Just as apt and yum manage this process for Linux, Helm handles it for Kubernetes. 

Helm Features

• Kubernetes management of components’ and applications’ deployment lifecycle
• Template-based definition that supports portability across deployment environments (e.g., Development, QA, Production)
• Hooks mechanism to inject use-case-specific code at various points in the deployment lifecycle
• Deployment testing framework  

Helm Constructs

Using Helm is a matter of installing a single executable. The helm command provides more than 20 parameters used in building, deploying, deleting, rolling back, etc. the deployment of an application to a Kubernetes cluster. 

The Helm deployment artifact is a Helm Chart. Helm Charts consist of resources used to deploy a component or application to a Kubernetes cluster. The most common resources within a chart are YAML files, which follow standard Kubernetes resource descriptions. For those experienced in deploying to a Kubernetes cluster using commands such as kubectl create or kubectl apply, the YAML files within a Helm Chart will look familiar. Helm Charts will often contain additional resources, such as README files, a default parameters file, and additional files (such as certificates) required for deployment.

Developing a Helm Chart requires assembling files using a predefined directory structure. The Helm command, helm create <chart name>, creates a Helm Chart, which is the predefined directory structure and includes some sample files. The generated chart contains several YAML files. A Kubernetes deployment often requires multiple Kubernetes resource descriptions to be deployed, and in many cases, there’s an order of precedence to which those deployments must occur. When deploying manually, the order must be known. This is not the case with Helm since Helm is aware of the order of precedence of Kubernetes resource descriptions.

A key feature to the Helm deployment process is Chart Hooks. During a Helm Chart’s deployment lifecycle, Chart Hooks are a mechanism by which additional tasks are performed. Helm supports several points to introduce a Chart Hook:

Table source: "The Available Hooks — Chart Hooks," Helm Documentation

Helm Charts can depend on other Helm Charts. For example, an application may contain dependencies on a collection of microservices where a microservice is defined by its own Helm Chart. When the application is deployed, Helm manages the dependencies. In keeping with the microservice pattern, each one can be updated independently of the rest so that it is still a cohesive part of an application’s collective definition. 

Planning a Helm Deployment

Helm plays a part in all aspects of application development and deployment, and that requires engineering and operations teams to work closely together to design solutions and answer deployment questions. With the teams coordinating, deployment decisions can be made iteratively, accommodating the variance in each deployment environment with the goal of having a single deployment package to support each environment. 

Beyond the concept of hooks previously described, Helm enables teams to tackle this challenge of a single deployment package by providing a robust templating mechanism. Typically, YAML files in a Helm Chart do not look like a handwritten YAML Kubernetes resource description. Rather, YAML files in a Helm Chart are developed using Helm’s template language: 

{{- if .Values.ingress.enabled -}}
{{- $fullName := include "helm-demo.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}
kind: Ingress
metadata:
  name: {{ $fullName }}
  labels:
    {{- include "helm-demo.labels" . | nindent 4 }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  {{- if .Values.ingress.tls }}
  tls:
    {{- range .Values.ingress.tls }}
    - hosts:
        {{- range .hosts }}
        - {{ . | quote }}
        {{- end }}
      secretName: {{ .secretName }}
    {{- end }}
  {{- end }}
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          {{- range .paths }}
          - path: {{ .path }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: {{ $svcPort }}
          {{- end }}
    {{- end }}
  {{- end }}

This sample ingress description, as generated by helm create, is templated, providing several variables by which an ingress resource is defined and configured, including whether the ingress resource should even be created. With templating, Helm offers a great deal of control over how Kubernetes resources are deployed. A well-planned templating pattern leads to producing a single deployment package that enables a Helm Chart to deploy successfully, ranging from a single-node Kubernetes cluster on a developer’s workstation to production Kubernetes clusters. 

Helm Charts and CI/CD

As part of an organization’s continuous integration/continuous delivery pipeline, Helm plays the roles of enabler and component. As an enabler, it enhances a pipeline by becoming the mechanism that deploys applications or components across the spectrum of environments (engineering, QA, staging, certification, production, etc.). Automating Helm Chart deployments is straightforward within a CI/CD pipeline.

As an application component, just as application code is iteratively developed and deployed, so are Helm Charts. This means that the CI/CD pipeline is integral in validating the Helm Chart itself. In fact, a Helm Chart should be considered part of the application code and not treated as a peripheral aspect of an application’s development process — even going so far as to include and manage the Helm Chart as part of the application’s source code. Similar to how an application build might produce a versioned container image and push it to an image registry, helm package bundles a chart into a versioned archive. The resulting archive is submitted to a Helm Chart repository, from which it can be accessed for deployment. 

The diagram above highlights stages in an application’s software development lifecycle. Whichever pattern is used in managing a Helm Chart’s source code, its participation in an application’s CI/CD pipeline is as integral as the application itself.

The Maturing of the Kubernetes Toolset

Helm has been a part of the Kubernetes ecosystem hype curve, and, as the Kubernetes hype curve has started to flatten, Helm has matured as well. Is Helm revolutionary in its approach? Not really. Helm leverages years of knowledge gained with the package and configuration management tools that have come before it, bringing that experience to Kubernetes. At the same time, Helm’s perspective in defining deployment packages via Helm Charts makes a direct impact on the efficiency of an organization’s CI/CD pipeline, most notably around configuration patterns and deployment flexibility. A well-designed Helm Chart is an integral component of effective delivery.  

This is an article from DZone's 2021 Kubernetes and the Enterprise Trend Report.

For more:

Read the Report