For cloud-native developers, Kubernetes is a powerful open-source system for automating the deployment, scaling, and management of containerized applications. But, there are a few things that are outside the scope of Kubernetes that make it difficult to work with. 

This is where an open-source package manager like Helm comes into the picture to plug the usability gaps in Kubernetes and enhance its capabilities. Helm provides a set of commands for automating the creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters.

What is Helm?

To put it simply, if Kubernetes were an operating system, Helm would be the package manager. Ubuntu uses apt, CentOS uses yum, and Kubernetes uses Helm. 

The original goal of Helm was to provide users with a better way to manage all the Kubernetes YAML files we create on Kubernetes projects. The path Helm took to solve this issue was to create Helm Charts.

Helm deploys packaged applications to Kubernetes and structures them into charts. The charts contain all pre-configured application resources and put all the versions into one easily manageable package. 

Helm streamlines installing, upgrading, fetching dependencies, and configuring deployments on Kubernetes with simple CLI commands. Software packages are found in repositories or are created.

Why Do We Need Helm?

Kubernetes objects are challenging to manage. There are multiple independent resources to deal with, and each requires a dedicated YAML manifest file. 

Helm automates the maintenance of YAML manifests for Kubernetes objects by packaging information into charts and advertises them to a Kubernetes cluster. The Kubernetes learning curve becomes smooth and manageable with helpful tools like Helm.

It keeps track of the version history of every chart installation and change. Rolling back to a previous version or upgrading to a newer version is completed with comprehensible commands.

What Can You Do With Helm?

Helm allows software developers to deploy and test an environment in the simplest possible way. Less time is needed to get from development and testing to production. Besides boosting productivity, Helm presents a convenient way for developers to pack and send applications to end users for installation.

How Does Helm Work?

Helm and Kubernetes work like a client-server application. The Helm client pushes resources to the Kubernetes cluster. The server-side depends on the version: Helm 2 uses Tiller, while Helm 3 got rid of Tiller and entirely relies on the Kubernetes API.

What Is a Helm Chart?

Helm charts are Helm packages consisting of YAML files and templates which convert into Kubernetes manifest files. Charts are reusable by anyone for any environment, which reduces complexity and duplicates. Folders have the following structure:

How Do Helm Charts Work?

The three basic concepts of Helm charts are

1. Chart – Pre-configured template of Kubernetes resources.

2. Release – A chart deployed to a Kubernetes cluster using Helm.

3. Repository – Publicly available charts.

Helm Chart Structure:

Each file and directory in a Helm chart have specific functions.

Case Study – Deploying apps in Kubernetes using Helm

To showcase our capabilities in containerized app deployment, the developers at Siam Computing used Helm to push an application on a Kubernetes cluster. Our observations and learnings are listed in this case study.

 The Project Flow 

Now, let’s dig deeper into the project flow as shown in the diagram:

1. When a developer pushes the code into a GitHub, it must deploy on the destination automatically. Much manual work is involved at this stage, and mistakes tend to happen during every new change. To avoid that, the following tools are used.

• Git – Version control tool

• Jenkins – CI CD tool

• Docker – Containerization tool

• Helm – Kubernetes package manager

• EKS – Elastic Kubernetes service provided by Amazon

• EFK – The monitoring tool gives an overall picture of all the resource statuses.

2. When code is pushed into a Github, it is triggered to Jenkins using the webhook method. GitHub and Jenkins are integrated, so Jenkins is intimated whenever new code is pushed in a GitHub.

3. Once a signal is received from Github to Jenkins, Jenkins will start a build using a new code. Once the build is completed by utilizing a docker file, Jenkins would create an image using the new artifacts. 

4. After image creation, Jenkins pushes the image to a Docker Hub. Then using Helm and the Artifact Image, the application gets deployed on a Kubernetes cluster without any manual or human errors.

Notes and Observations:

1. By using simple Helm commands, one can manage the cluster easily. There is no need for Kubernetes commands when Helm is used.

2. Another distinguishing feature of Helm is the ability to customize application configurations during deployment. The DevOps team can provide configurations for all the Kubernetes resources included in the application and configure all the environment-specific requirements for those resources. This enables teams to reuse one Helm chart across multiple environments (Development, UAT, Live).

3. If something goes wrong, it can be rolled back to earlier versions without worrying about other dependencies. It facilitates problem-free deployment easier.

4. Overall, the app was deployed without any hiccups, and Helm Charts were used to manage the environment.

Six Benefits of Using Helm

From our first-hand experience of using Helm to deploy apps on Kubernetes, we have seen that it is a very reliable, efficient, and tension-free process. Listed below are some of the reasons why we feel Helm could make the lives of Dev-ops engineers easier.

1. Helm Charts provide the ability to leverage Kubernetes packages with just a click of a button or single CLI command. You can also include Helm charts within other Helm charts and have various dependencies.

2. Helm charts are built atop Kubernetes. These charts complement the cluster architecture of Kubernetes. While using Helm for deploying applications to Kubernetes, scalability is a default benefit from the very start, as all the charts of the container images used by Helm are stored in a registry called Helm Workspace, which the DevOps teams can look up and add to their projects with ease.

3. Another distinguishing feature is the ability to customize application configurations during deployment. The DevOps team can provide configurations for all the Kubernetes resources included in the application and configure all the environment-specific requirements for those resources. This enables teams to reuse one Helm chart across multiple environments.

4. Helm is a must-have for Kubernetes deployments. But the real benefits lie in its role in streamlining your CI/CD pipelines.

5. Helm automatically maintains a database of all the versions of your releases. So, rolling back to the previous version is just one command away whenever something goes wrong during deployment.

6. Several CI/CD integration hooks available in Helm enable teams to automate specific actions by default, just like macros in Microsoft office, for example, before installation begins or after an upgrade has finished. You can schedule health checks for Helm to verify if a deployment has been completed successfully.

Picture Credits – Unsplash

Wrapping Up…

Helm is a powerful tool that can be used to quickly deploy and manage your Kubernetes cluster with just a few commands. It has been adopted by many companies and organizations and will continue to be used in the future.

Do you want someone to deploy and manage your apps in the Kubernetes cluster? Reach out to us, and we’ll help you run your app on Kubernetes without any hassle.