Kubernetes Package Management With Helm

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

For more:

Read the report

Presentation Helm

Helm is the package manager for Kubernetes. Given a running Kubernetes pool of any type, Helm is used to manage the deployment lifecycle of nearly any type of Kubernetes resource, including the management of many Kubernetes runtime components. A very common analogy used to describe Helm is that Helm is Kubernetes as appropriate for Debian-based systems and yum or rpm for Red Hat-based systems. In addition to package management, many aspects of configuration management are also included in Helm. Helm was initially developed by a company called Deis, which was acquired by Microsoft. Microsoft has fully supported and accelerated the development of Helm, and is now part of the Cloud Native Computing Foundation (CNCF).

Helm History

Image source:Helm History– Slide from Helm’s project presentation to CNCF TOC, May 2018

As part of CNCF, Helm has been actively developed and supported by many organizations, and since then has developed a large and active community. Here is a sample of the Helm project’s contribution statistics as of October 2021:

contributors abide icon Withdrawal requests contributions
15,449 17.079 16897 152442

Table source: “Project Statistics General Table”, CNCF . Helm DevStats project

Why a package manager for Kubernetes?

Like most technologies, the “Hello World” examples provide basic concepts, and Kubernetes is no exception. Deploying anything beyond the most direct component to a Kubernetes cluster requires coordination across multiple components. For example, the process of managing an application deployment outside the Kubernetes cluster is not complicated. However, it is tedious because there are dependencies, dependency versions, configuration stuff, pre- and post-deployment steps, validation, etc. Just as with a convenient and yum management of this process for Linux, Helm handles it for Kubernetes.

helmet features

  • Kubernetes management of the component and application deployment lifecycle
  • Template-based definition that supports portability across deployment environments (eg development, quality assurance, production)
  • Hooks mechanism for injecting use-case code at different points in the deployment lifecycle
  • Deployment Test Framework

Helm Building

Using Helm is a matter of installing a single executable. the helm The command provides more than 20 parameters that are used to create, publish, delete, retrieve, etc., deploy an application to a Kubernetes cluster.

Helm Deployment Tool is Helm Chart. Helm schemas consist of the resources used to deploy a component or application to a Kubernetes cluster. The most common sources within the schema are YAML files, which follow standard Kubernetes resource descriptions. For those experienced in deploying to a Kubernetes cluster using commands like kubectl create or kubectl applyYAML files inside a Helm schema will look familiar. Helm schemas often contain additional resources, such as README files, a default parameter file, and additional files (such as certificates) that are required for deployment.

Helm schema development requires compiling files using a predefined directory structure. Helm command, helm create <chart name>, creates a Helm schema, which is the predefined directory structure and includes some sample files. The generated graph contains several YAML files. Deploying Kubernetes often requires publishing multiple Kubernetes resource descriptions, and in many cases there is an order of precedence for these deployments to occur. When deploying manually, the command should be known. This is not the case with Helm because Helm is familiar with the order of precedence of descriptions of Kubernetes resources.

The main feature of Helm Deployment is Chart Hooks. During the Helm Chart deployment lifecycle, Chart Hooks are a mechanism by which additional tasks are performed. Helm supports several points for rendering a binding scheme:

connect chart Describe
pre-install Perform tasks before publishing the application
post-install Perform tasks after application deployment
pre-delete Perform tasks before removing an application from the block
post-delete Perform tasks after removing the application from the block
pre-upgrade Execute tasks before performing the upgrade of a published application
post-upgrade Execute the tasks after the upgrade of the published application is completed
pre-rollback Execute the tasks before performing the undo operation of the published application
post-rollback Execute tasks after undoing a published app is completed
test Executes Helm tests as specified in the Helm . schema

Table source:Available hooks – chart hooksHelm Documentation

Helm charts can be based on other Helm charts. For example, an application may have dependencies on a set of microservices where the microservice is defined by its Helm schema. When the application is deployed, Helm manages the dependencies. In keeping with the pattern of microservices, each one can be updated independently of the rest so that they remain a coherent part of the application’s collective definition.

Planning to deploy a helmet

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

Combined with the concept of hooks described earlier, Helm enables teams to meet this challenge of a single deployment package by providing a robust template mechanism. Normally, YAML files in a Helm Chart don’t look like a handwritten YAML Kubernetes resource description. Alternatively, YAML files are developed in Helm Schema using Helm 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 entry description, as generated by rudder generation, is typical, providing several variables by which the input resource is defined and configured, including whether or not the input resource should be created. With templates, Helm provides a great deal of control over how Kubernetes resources are deployed. A well-planned template pattern produces a single deployment package that enables Helm Chart to successfully deploy, from a single-node Kubernetes cluster on a developer’s workstation to productive Kubernetes clusters.

Helmet diagrams and CI/CD

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

As an application component, just as application code is frequently developed and published, so are Helm diagrams. This means that the CI/CD pipeline is an integral part of validating the Helm schema itself. In fact, the Helm Chart should be considered part of the application code and not treated as a secondary aspect of the application 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 building a versioned container image application and pushing it to an image history would result in, helm package Packages a schematic in a versioned archive. The resulting archive is sent to the Helm Chart repository, where it can be accessed for publishing.

Stages of the application software development life cycle

The above diagram shows the stages of the application software development lifecycle. Whatever pattern is used to manage the Helm Chart source code, its participation in the application’s CI/CD pipeline is an integral part of the application itself.

Kubernetes Toolkit Maturity

Helm has been part of the Kubernetes noise curve, and as the Kubernetes noise curve begins to flatten, Helm has matured as well. Is Helm revolutionary in his approach? Not real. Helm leverages years of knowledge gained through the package and configuration management tools that came before it, bringing this experience to Kubernetes. At the same time, Helm’s perspective on defining deployment packages via Helm Charts directly affects the efficiency of an organization’s CI/CD pipeline, most notably around configuration patterns and deployment resilience. A well-designed Helm chart is integral to effective delivery.

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

For more:

Read the report

.

Leave a Comment