Kubernetes was started inside Google to provide a layer of abstractions with containers for the modern infrastructure. Now, the technology is adopted by the masses and has become a de facto standard for any cloud native application. The open source system provides management, deployment, and scaling of your containers.
Kubernetes is hard to beat in orchestration, but one of the most significant drawbacks is its lack of reproducibility. Here comes Helm: A package manager for Kubernetes and a CNCF Graduate Project.
I was thrilled to speak at DoK Talks on the 114 Edition about Helm and how it tackles the reproducibility problem for Kubernetes. This post will be a summary of the beginner focused event which took place on 27th January 2022.
It's not required for you to go through the recordings as this is a very extensive summary and going through this will give you a basic understanding of Helm!
What’s the reproducibility problem?
After you have deployed your application with numerous objects: Deployments, Services, ConfigMaps, etc., how do you help your friend get to a similar state? Of course, you will share your YAML files with your friend. Correct?
Yes and No!
You can do the hard work of copy and pasting for a small application, but what if your application is a full-stack web app with 100s of configuration files. Can you still copy them? No, you can’t, as it’s prone to errors with that many large numbers.
Even if you send the object manifest to your friend, there’s one question still available. How would your friend convert site to site, or maybe change how much resource each application consumes? Will he go through the 100 manifests? No, that’s not scalable, prone to errors, and wastes a lot of time.
Now suppose there’s a security flaw on one of your dependencies. How will you update them? Find your YAML, or edit your live resources? Absolutely NO!
You need a saviour. You need Helm to your rescue.
What is Helm?
Helm is your saviour for the reproducibility problem, a package manager, and a CNCF graduate project. It was launched in 2016 and has seen massive adoption among organizations, individuals since then. Under the CNCF Umbrella, Helm has become the de facto package manager for your clusters.
What does Helm do?
Helm helps you to achieve reproducibility in the following ways:
- Provides an easy way to deploy complex application
- Provides easy way to update specific values for your deployments
- Provides a way to version a particular package
- Provides a way to share your templates across organisation, Internet
- Provides an easy way to manage dependency
- Provides an easy way to rollback changes
Architecture of Helm
The Helm Repository contains all the charts (packages) created by you or other people that you can use to reach the desired state. The Helm CLI pulls the package, unarchives it, and then converts the charts to a valid YAML, which is then pushed to Kubernetes API server, which creates a release.
Basic Components of Helm Charts
A basic Helm Chart has the following structure:
package-name/
charts/
templates/
Chart.yaml
values.yaml
charts/: This directory can be used to store manually maintained chart dependencies.
templates/: These contain the template files which would be used to create the final manifest after combining with values.yaml.
Chart.yaml: This file contains information about the chart, such as the name and version of the chart, the maintainer, dependencies, a related website, and search terms.
values.yaml: This contains the default configuration for your charts. You can edit this for updating values and remove the complexity of finding specific editable items in the different manifests.
The below example shows a deployent.yaml from templates being rendered with the custom values from values.yaml to produce the valid YAML.
Helm Templates Creation with values.yaml
How to edit the default values?
Manually pulling the charts and unzipping it to edit your values.yaml is not that straightforward. We have Portainer here, which does all the heavy lifting for you and helps you to get straight to editing the default configuration.
First Navigate to Helm from the Menu and then add a repository. In a standard installation of Helm, you need to add a repository, but with Portainer, you get Bitnami by default and can add more when required. Select a namespace and an application name. Then you need to select the chart you want to deploy to your cluster.
Once selected, you can navigate to a chart, and Portainer will load the values on your dashboard for you to edit. Editing values are straightforward and abstract the complexity you had to deal with manual installation and initialization via a simple GUI.
The Install button would install your chart with the specified values to your cluster. If you want to go with the default values, click on Install without editing the values.
After installation, Portainer detects and shows you Published URLs to access your applications and secrets for you to access default passwords. Forget digging through commands to get to your Services and Secrets.
Final Thoughts
Helm abstract the complexity of installing applications to your cluster. Portainer abstracts the complexity of managing your cluster. This post went through how Portainer can help you simplify your Kubernetes workflows with Helms.
Try Portainer now and learn more about the different ways to streamline managing Kubernetes with our documentation.
Portainer Documentation for Helm here: https://docs.portainer.io/v/ce-2.11/user/kubernetes/helm
Recordings are here:
Top comments (0)