.svg)
Probably one of the first packages installed after your Kubernetes cluster is up and running is Helm. A stalwart in the Kubernetes ecosystem, Helm is a package manager for Kubernetes. If you are unfamiliar with Helm, Helm helps users to have a more consistent deployment by packaging up all of the needed resources needed for a Kubernetes deployment. If you are used to authoring package manager instructions, Helm will follow most of those conventions.
Though like anything in Kubernetes, release/operations and development tasks are merging and if coming from an application development background, Helm would fall under the release side of the equation. Even if you are not authoring Helm instructions, Helm is a popular installation method for many software vendors and projects to install resources on your Kubernetes cluster. As complexity started to increase in Kubernetes, Helm was introduced at the very first KubeCon in 2015.
2015 was a milestone year for Kubernetes. Kubernetes finally had the first general availability release after being in the community for over a year, with 1.0 in the Summer of 2015. Since Kubernetes is designed to be pluggable and the “platform of platforms,” there was a need to start orchestrating multiple Kubernetes configuration files. Helm was originally developed by Deis, a firm dedicated to helping the Kubernetes Ecosystem, which was later acquired by Microsoft. Deis, as a fun fact, is also one of the original sponsors of The Children’s Guide to Kubernetes.
Helm, since its inception, has been designed to be a package manager. Helm is currently on it’s third rendition, with Helm V3. It garnered a lot of adoption with its second rendition, Helm V2, which is end of life as of Summer 2020. Helm certainly has more competition and alternatives now as the project continues to evolve, but the project continues to stay true to its package management roots and goals.
Package management is not a new concept. If you have used a Linux Machine before, package managers, such as YUM/RPM and APT, are crucial to the installing and uninstalling of software packages. If Linux is not your flavor, using a package manager such as Homebrew on your Mac or Chocolatey for Windows makes installing software, especially development software, easier.
As the Kuberenetes platform and ecosystem continued to expand, deploying one and only one Kubernetes configuration file (ie: a single YAML) was not the norm anymore. There could be multiple clusters to deploy to and multiple resources to orchestrate inside Kubernetes. As the number of YAMLs increased, where to even store these YAMLs became an issue. Enter Helm to solve these problems.
If there is a need to orchestrate more than one Kubernetes resource and if there are multiple clusters with different configurations, you have a strong use case for leveraging Helm. Software vendors and open source projects alike can benefit by providing Helm resources, such as a Helm Repository and Chart, as a way for consumers to install applications into Kubernetes clusters.
Helm uses a packaging format called Charts. A Helm Chart is a collection of files that describe a set of Kubernetes resources. Like other package manager formats based on convention, Helm Charts follow a directory structure/tree. The Helm Charts can be archived and sent to a Helm Chart Repository.
In its current rendition, Helm is a client that is installed outside the Kubernetes cluster. It leverages kubectl to connect and interact with the Kubernetes cluster. Helm will use the connection information provided by kubectl. There are several methods for installing the Helm Client, depending on your operating system. On your Mac with Homebrew, you can simply run brew install helm. With Helm installed, it’s time for you to reap its benefits.
The big benefits to using Helm are pretty similar to CI and CD goals: repeatability and consistency. With Kubernetes, installation complexity did not disappear; the old computer science adage that you are just moving complexity around like an abacus is true. Treating the installation and uninstallation steps like a piece of software has benefits.
For the consumer of Helm Charts, this can be a fast pass in consuming and deploying software on your Kubernetes Cluster. Want to start playing around with new technology like Prometheus? You can hand write the installation steps or just add the Helm Chart Repository for Prometheus then just run helm install stable/prometheus.
Helm packaging is not just limited to software vendors or open source projects. All organizations install and deploy software. As investments in Kubernetes continue, using a package manager reduces duplication and complexity in orchestrating the steps defined in the package manager. What needs to be authored to leverage Helm for your internal/custom-created applications is a Helm Chart and associates structure and values.
A Chart is the primary format in which Helm runs off of. Since Helm Charts are file-based and follow a convention-based directory structure, Charts can easily be stored in Chart Repositories. Charts are installed and uninstalled into Kubernetes clusters. Like the image-to-container relationship, a running instance of a Chart is called a Release. In the end, a Helm Chart is an executed template converting Chart definitions to Kubernetes manifests.
Helm Charts, when created, must have a version number that follows semantic versioning. Helm Charts can reference other Charts as dependencies, a core to any package manager. More advanced features of Helm Charts are Chart Hooks and Chart Tests, which allow for interaction with a Release’s lifecycle and the ability to run commands/tests against a Chart respectively. The great thing about a Helm Chart is if you are learning, you can explore the contents of the Chart since they are file-based. If you are authoring your first Helm Chart, there are four main components to focus on.
The project’s Getting Started guide is a great resource for understanding the contents of a Chart. Inspecting Bitnami’s MySQL Chart on Github will give you a good idea of the structure and content of a widely-used Chart.
The four main components that are required for a Helm Chart to be executed are as follows:
Your Chart.yaml has required information describing what the Chart is about, with a name and version. There is more information that can be included in the Chart.yaml, but that is the minimum.
The Values.yaml file is where you define values to be injected/interpreted by the templates. Imagine this as a properties file. In combination with the templates, the values will be used to create Kubernetes manifests.
Templates are integral to using Helm. The Template Directory is where existing Kubernetes manifests can leverage the values in Values.yaml and if resources need to be generated, additional YAMLs can be generated with Templates. Helm leverages Go Templating if there is conditional logic needing to be included in the Templates. If you are not leveraging some sort of Templates, Helm might not be a good use case for you as a producer.
With those pieces out of the way, Helm can execute on your Chart. If you were leveraging Helm prior to the current Helm V3, Tiller would be a piece that is needed to interact with your Kubernetes Clusters.
If you are familiar with Helm V2, Tiller was a part of the Helm Platform. It came from the part of the project integration with Google’s Deployment Manager and was designed to be a job runner, not too dissimilar to Cloud Foundry’s Bosh. In a nutshell, Tiller is the in-cluster portion of Helm that runs the commands and Charts for Helm. Because Tiller had unfettered access to the Kubernetes Cluster, it became a sore point for cluster security, and the rise of alternatives to Helm followed.
Package management - and now configuration management - are important pieces of operational functionally that organizations embracing Kubernetes workloads quickly require. Helm has certainly faced competition, and the most prevalent competition is with the rise of Kustomize, though there are several alternatives to Helm depending on your approach. Each alternative is another approach for templating inside of Kubernetes.
According to both projects, Helm and Kustomize are two different approaches. Kustomize focuses on configuration management, while Helm focuses on package management. Where Kustomize gained a lot of popularity was the ability not to use Tiller when compared to Helm V2 and leverage native kubectl commands from day one.
Jsonnet is a templating language and engine. Jsonnett has an object-oriented approach for templating, allowing for complex and relationship-based templates to be created. If you need to make replicas of something, simply create a new object and the backing template will take over. Ksonnnet was a fork of Jsonnet specifically designed for Kubernetes and created by Heptio. Though, as of recently, the team behind Ksonnet is no longer supporting the project.
Skaffold is one of the latest Kubernetes management projects from Google. Skaffold is more encompassing than Jsonnet, Helm, and even Kustomize. Since Skaffold has build and deploy components, it is designed to be the one recipe needed for a Kubernetes application. Skaffold is pluggable for the deployment phase with Helm and Kustomize.
No matter what you pick for your Kubernetes goals, Harness has you covered. Leveraging Helm in Harness is pretty easy.
Getting up and started with your first Helm V3 deployment is pretty straightforward with Harness. An easy path is to leverage a Harness Kubernetes Delegate. Getting the Kubernetes Delegate installed and a Kubernetes cluster wired up is described in the Kubernetes Quickstart.
Go through the steps below to deploy a Helm Chart for a popular distribution, Nginx.
The first step would be to add a Helm Repository to Harness.
To add, go to Setup -> Connectors -> Artifact Servers + Add Artifact Server.
Type: Helm Repository
Display Name: Bitnami Helm Repo
Repository URL: https://charts.bitnami.com/bitnami
Hit Test to validate the location then Submit to add the repository.
Harness runs off a CD Abstraction Model. A Harness Application is the epicenter of the Abstraction Model.
To create a new Harness Application, Setup -> Applications + Add Application.
Create a new Application called “Helm in a Handbasket.”
Once you hit Submit, your canvas is there to build upon.
A Harness Environment defines where you are going to deploy.
To add a Harness Environment, Setup -> Helm in a Handbasket -> Environments + Add Environment.
Name: Test Environment
Environment Type: Non-Production
Once you hit Submit, the next step is to add an Infrastructure Definition defining the target infrastructure, which in this example, is only one Kubernetes cluster.
Setup -> Helm in a Handbasket -> Environments -> Test Environment +Add Infrastructure Definition
Name: Helm Cluster
Cloud Provider Type: Kubernetes Cluster
Deployment Type: Kubernetes
Cloud Provider: <your_Kubernetes_cluster>
Once you hit Submit, the Infrastructure Definition is complete.
A Harness Service is what you are going to be deploying. Here you can link to the Helm Chart you would like to deploy.
To add a Harness Service, Setup -> Helm in a Handbasket -> Services + Add Service
Name: Bitnami_Nginx
Deployment Type: Kubernetes
Once you hit Submit, on the right-hand side of the Service, click on the three ellipses to Link Remote Manifests.
Add a Helm Chart as the Remote Manifest.
Manifest Format: Helm Chart from Helm Repository
Helm Repository: Bitnami Helm Repository
Chart Name: bitnami/nginx
Chart Version: 8.2.0 [which is the latest as of this blog post]
Helm Version: v3
Hit Submit and the Manifest will be there.
If you don’t know what version of a chart to use, you can leverage the Helm CLI on your machine and add the Bitnami Repository and search for the Chart.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm search repo bitnami/nginx
The last step is to define how you are going to deploy with a Harness Workflow.
To create a new Workflow, Setup -> Helm in a Handbasket -> Workflows + Add Workflow.
Name: Deploy Nginx
Workflow Type: Rolling Deployment
Environment: Test Environment
Service: Bitnami_Nginx
Infrastructure Definition: Helm Cluster
Once you hit Submit, the Workflow will be completed and it’s time to deploy.
There are a few ways to deploy in the Harness Platform. You can go back to the Workflow and click Deploy on the top right. Another way is through the Continuous Deployment menu in the left-hand navigation.
Continuous Deployment -> Deployments -> Start New Deployment.
Execute a Workflow Directly: Selected
Workflow: Deploy Nginx
Hit Submit and you are on your way!
There is a lot of the art of the possible with the Harness Platform to roll out changes to a wide swath of Kubernetes clusters.
No matter your technology choices or Kubernetes topology, Harness and Helm are better together. One of the limitations of Helm without a delivery platform is that Helm leverages your kubectl context, so there is administration switching between clusters. In Harness, you can model your distributed topology even across cloud providers for a seamless experience.
For further reading on Helm, read up on Helm vs. Kustomize.
Cheers!
-Ravi
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
