Helm Charts in Kubernetes

[weaveworks]

It’s 2015 and after being in the community for over a year, Kubernetes has finally had its first general availability release. It is a plug-and-play platform ‘for platforms’ that makes it extremely popular in the cloud-native ecosystem. But now, dealing with Kubernetes objects can easily become complex. This has led to the need to start orchestrating multiple Kubernetes configuration files.

Typically, an application deployed on Kubernetes has objects such as deployments, configmaps, vertical and horizontal pod autoscalers, ingress, secrets, services, pods, etc. And everything is defined using YAML files, given its declarative nature. Now, every environment requires its own set of YAML files, which again require maintenance.

That’s when we use Helm — the most widely accepted tool to manage software built for Kubernetes and developed by a community of 400+ developers. In this article, we will dive deeper into what Helm Charts are and how they fit into the Kubernetes workflow, and how you can benefit from them.

Source: Helm

What is a Helm Chart in Kubernetes?

Created initially by Deis Labs and later donated to CNCF, Helm is an open-source project with the original goal to help provide users with an easier way to manage all Kubernetes YAML files. 

To better solve this issue, Helm Charts were created. Each Helm Chart is a bundle with multiple Kubernetes manifests which means a chart can have child charts and charts dependent on it. In short, Helm can install the entire dependency tree of your project from a single install command for the top chart.

With Helm Charts you can go all the way from defining to installing and upgrading complex Kubernetes applications. You can version your manifest files too, meaning you can install specific chart versions stored in the form of code. Plus, Helm maintains a release history of all deployed charts, so you can revert the changes if something goes sideways.

Furthermore, you don’t have to write any new syntax files to start using Helm since it supports Kubernetes natively.

Why should you use Helm?

Package managers like Homebrew, Chocolatey, and yum are commonly used to install new software but Helm is the only package manager with specific support for Kubernetes applications. Once you package your applications as a Helm Chart, you can install, update, and roll back your applications with a few commands. For starters, you can even make use of some of the pre-packaged, production-ready charts for well-known software apps like MySQL, NGINX, and MongoDB from ArtifactHUB or Bitnami. But there are many factors that make the Helm architecture superior.

The initial versions of Helm had a client-server architecture that needed separate installations. It had the CLI on the client side and a component called Tiller on the server side (which was later removed for certain security reasons). Helm v3, now, is a client-only utility and has numerous benefits, including: 

• High productivity: You can deploy Kubernetes packages from a single command on the CLI and even include all the dependent charts in one go just as you can use Helm to deploy your applications in test environments at the click of a button. For instance, suppose you need to create a new database. Instead of installing an SQL client locally, you can simply run a single Helm Install command to create new databases.

• Simplified deployments: Streamlining your CI/CD pipeline is easier than ever before. You have the option to customize your application configurations during deployment and reuse a Helm Chart across different environments. Again, you can use Helm Charts to set overridable defaults in the values.yaml file to allow administrators to predefine certain settings. The Helm Chart users can later override these settings (if required) according to their requirements. Furthermore, you can use Helm’s CI/CD integration hooks to automate most of your pre- and post-deployment actions.

• Simplified rollbacks: Rollbacks are now highly simplified. In case there is a deployment issue, you can revert to one of the previously released versions with a simple helm rollback command. You can specify the specific version to which you want to roll back to, and if not, you can leave the argument blank and it will simply roll back to the version immediately before it.

• Gentle Kubernetes learning curve: The Kubernetes learning curve for an average developer is usually pretty steep. Helm helps smoothen this curve by hiding most of the details that developers don’t need while deploying container applications. Hence, you can focus on writing the application code and not deployment.

With different objects being tightly coupled with each other, deploying applications isn’t a simple process. Unless you know the specific purpose of each object, it can get extremely difficult to make a successful deployment. Helm helps minimize that complexity. 

Describing a Helm Chart

When you create a new Helm Chart, you must follow a certain structure. First off, you run the helm create <chart-name>. Once the chart is created, the file structure looks like this:

CHART-NAME
  .helmignore
  chart.yaml
  values.yaml
  charts/
  templates

The .helmignore contains all the files that will be ignored when the chart is packaged. It is the Helm’s equivalent of Git’s .gitignore file.

The chart.yaml is where you will store all the information related to your chart. This includes the name, the chart version, and the description (which can be viewed if published in an open repository). Additionally, using the dependencies key, you can define all the external dependencies.

The values.yaml file contains default values that will be used for variables. It is the Helm equivalent of Terraform’s variable.tf file.

If your chart has dependencies on charts other than the ones belonging to Helm’s default library, you can include its structure inside the charts/ directory. As chart dependencies are installed from the bottom all the way to the top chart, you must install the independent chart first and then the ones that rely on it in that order.

Figure: 3-Tier Kubernetes Architecture - Source

templates is another directory where you place your manifest files to be deployed alongside the chart. Everything here will be later passed on and created in Kubernetes. For instance, you might have an application deployment that needs secrets, a configmap, and a service. All the yaml files for secrets, configmap, service plus the config.yaml will be placed in template dir and get their values from values.yaml as mentioned above.

How to create and use Helm Charts in practice?

The best way to start using Helm is to experiment with a simple example, but first, let’s install Helm with a simple command (for macOS):

brew install kubernetes-helm

You can use other package managers like Chocolatey or APT too for installing Helm on Windows and Linux respectively. Next, you can use Helm’s installer script for downloading the latest version:

$ curl -fsSL -o get_helm.sh 
https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

$ chmod 700 get_helm.sh

$ ./get_helm.sh

Once you have installed Helm in your OS, you may verify the installation with the helm version command which will give you detailed build information.

Figure: Helm Chart Architecture - Microsoft.com

Helm supports the following commands:

• completion: it autocompletes scripts for a given shell
• create: it is used to create a new chart with a specified name
• dependency: you can manage a chart’s dependencies with this command
• env: it gives you information about the helm client environment
• get: use it to download extended information of certain release
• help: gives you information about different Helm commands
• history: shows you the release history
• install: use it to install a certain chart from Helm’s default library
• lint: helps you examine a chart for problems
• list: describes a list of releases
• package: creates an archive out of a specified chart directory
• plugin: use it to install, uninstall, or show plugins
• pull: helps download a certain chart from a repository and unpack it in your local system if required
• repo: helps add, update, list, index, and remove chart repositories
• rollback: use it to revert to a previous version
• search: helps look for certain keywords in charts
• show: shows all the chart information
• status: shows the status of a specified release
• template: renders templates locally
• test: tests the specified release
• uninstall: accepts a release name and then uninstalls it
• upgrade: upgrades a specified release
• verify: verifies the validity of a chart at a given path
• version: shows the version of the Helm client

Of course, to run Helm, you must have a Kubernetes cluster. If you have one already, use it, or set up a local cluster. Next, let’s install NGINX using a Helm chart that’s pre-packaged and already available. The following command can be used to look for the chart in your local repository:

helm search repo nginx

If you get a warning about the bitnami repository being corrupt or missing, update it using ‘helm repo update’ which will update your chart repository post which you will have to rerun the search command above. Once you are able to see bitnami/nginx in the list, enter the following command:

helm install nginx bitnami/nginx

Now, there are multiple you can specify the chart you wish to install:

• Using a path to an unpacked chart directory:

helm install mynginx ./nginx

• Using a path to a packaged chart:

helm install mynginx ./nginx-2.4.6.tgz

• Using a chart reference:

helm install mynginx bitnami/nginx

• Using a chart reference along with a repository URL:

helm install --repo https://qwerty.com/charts/ mynginx nginx

• Using an absolute URL:

https://qwerty.com/charts/nginx-2.4.6.tgz

• Using OCI registries:

helm install mynginx --version 2.4.6 oci://qwerty.com/charts/nginx

You can later verify the installation by running the kubectl get all command. If the installation went through well, the output from the above command would show you the service, pod, deployment, and replica set Helm has created.

By running the helm list command, you can view all the releases that have failed or have been deployed. And if you’re using minikube as a local Kubernetes cluster, you can use the minikube service nginx command to gain external access to the service. 

The URL you get from the output of the previous command will lead you to your application.

Hereon, you can create Helm charts specific to your application using the helm create command.

Weaveworks Helm Support

Weaveworks helps enterprises across industries to gain cloud agility and deliver more customer value with GitOps. To that end, we have created numerous open-source tools including Flux, Flagger, and the Helm Controller. You can use Flux and Flagger to help deploy apps with feature flags, canaries, and A/B rollouts. Flux works with all prominent Git providers and can support all Kubernetes tooling including Kustomize, RBAC, and Helm.

Helm-controller, on the other hand, is a Kubernetes operator that you can use to manage all your Helm chart releases declaratively. Being a part of the GitOps toolkit, it relies on source-controller to get all the Helm Charts you may need from the existing Helm repositories. Plus you can use it to stay on the lookout for HelmRelease objects as well as generate Helm Chart objects. 

Figure: Helm Controller using Flux - Source

Helm-controller also supports HelmChart artifacts that are produced from Bucket sources and GitRepository sources. Using it, you can even automate various Helm actions such as testing, uninstalling, rollbacks, etc, and use its auto-remediation feature in case a Helm install/upgrade command fails.

Final Thoughts

For a long time teams have relied on Kubernetes YAML files to configure and manage their workloads. These YAML files require every bit of specific information for deploying containers. And there’s a unique YAML file for every workload. Helm helps with all that but it’s important you don’t lose sight of the bigger picture.  As a DevOps professional, you need to understand the extent of flexibility a tool gives you so your project delivery timeline isn’t sidetracked. 

Given its popularity and exhaustive list of features, learn more about how Helm Charts benefit your business and how Weaveworks can help. Request a demo now!

View the full article