Introduction to Helm
Features of Helm
Helm is a package manager for Kubernetes, used to simplify and enhance the deployment experience for deploying resources into a Kubernetes cluster.
This training course explores Helm 3, which is the latest version of Helm building upon the successes of Helm 2. During this course, you'll learn the fundamentals of working with Helm3, its features, and the key differences between Helm 3 and Helm 2.
Several hands-on demonstrations are provided within this course, which will allow you to observe how to install and set up Helm, and also how to use Helm to perform various Chart cluster management related tasks. You'll also see how to create and host your very own Helm Chart. All of the coding assets which are used and demonstrated can be found within the CloudAcademy GitHub repositories for this course — they can be found in the links under the Resources section below. You’re encouraged to clone these repositories and perform the same helm commands against your own Kubernetes cluster.
If you have any feedback about this course, please contact us at firstname.lastname@example.org.
By completing this course, you will learn:
- What Helm is and how to install it
- Helm charts, templates, releases, revisions, and repositories
- How to deploy, upgrade and rollback Helm charts
- How to create and host your own Helm charts
The intended audience for this course includes:
- Anyone interested in learning about Helm and its fundamentals
- Software Engineers interested in learning how to configure and deploy Helm charts into a Kubernetes cluster
- DevOps and SRE practitioners interested in understanding how to install, manage and maintain Helm-deployed infrastructure
To get the most out of this course, you should have:
- A basic understanding of Kubernetes
- Experience with deploying Kubernetes resources such as pods, deployments, services, etc.
- A basic understanding of software development and the software development lifecycle
If you’re completely new to Kubernetes, please consider taking our dedicated Introduction to Kubernetes learning path.
Welcome back. In this lesson, I'm going to provide a quick review of the basic commands that you'll often use when working with Helm. Before I drill into the specifics of each available individual command, it's useful to know that auto completion exists, if enabled, and that help can be consulted by specifying the,-help argument on any command.
The following Helm commands as displayed here are used for basic Helm chart management, that is, those which are used to find, pull, install, upgrade, rollback, and uninstall a chart. Starting with Helm Search, the search sub command has two further sub commands, hub and repo. Helm search hub is used to evaluate fuzzy-based searching for publicly registered charts, meaning the search keyword can be partial. Running this command with a keyword will result in a list of matching charts.
The search is performed through the centralized online Helm Hub, located at https://hub.helm.sh. The helm search repo command also provides a keyword search mechanism, but this time against the registered repositories locally. Running the command helm repo list will display the registered repositories. You can add additional repositories to search against by running the command helm repo add, which I'll review on the next slide.
The helm pull command is used to pull down a package from a package repository. When running this command, you provide it either with a chart URL or string composed of the repository name, chartname. As the documentation states, this is useful for fetching packages to inspect, modify, or repackage. It can also be used to perform cryptographic verification of a chart without actually installing the chart.
The helm install command is used to perform an installation of a chart. When installing a chart, you specify a name for it, together with the location of the chart itself. The location of the chart can be specified one of five different ways. A typical approach will be to specify the registered repository name, slash name of the chart. For example to install the wordpress chart with the name wordpress located in the locally-registered bitnami repository, use the command helm install wordpress bitnami/wordpress.
The helm upgrade command is used to upgrade an existing chart release, and results in a new revision being created for the release once applied. When running this command, you must specify both the release name and the chart. The chart itself may contain updates that potentially changes the behavior of the deployed application. Or equally, the chart may be unchanged and instead new values are being passed in as part of the helm upgrade command, which again results in a new revision and change of behavior.
The helm rollback command is used to rollback a chart release to a specific revision number. The first argument of the rollback command is the name of a release, and the second is a revision, or version number. If the second argument is omitted, it will roll back to the previous release. Note, this command can be used to move the current release back and forward. The revision history for a release can be displayed by running the command helm history together with the release name.
The helm uninstall command takes a release name and uninstalls the release. It removes all of the resources associated with the last release of the chart, as well as the release history, freeing it up for future use. Moving on, the following group of commands are focused on managing and maintaining Helm repositories.
The helm repo add command takes both a name and URL as its arguments. The name is used to reference the repository later on, when using other helm commands such as helm install or helm upgrade. The URL refers to the location of the repository, which can be either public, hosted on the Internet, or private, hosted on an internal network.
The helm repo list command simply lists out the registered helm repository list, including both name and URL for each registered repository. This command can take a --output parameter which alters the format of the outputted list. This parameter can be set to any of the following values, table, JSON, or yaml, with table being the default when this parameter is absent.
The helm repo remove command takes a repository name and then removes that particular repository from the currently configured repository list. The helm repo update command updates the latest information about charts from the respective chart repositories. Chart information is cached locally, where it is then queried on by other helm commands, for example the helm search repo command.
When it comes to hosting your repositories, use the helm repo index command to scan the current file system directory and generate an index file based on all charts found within it. Moving on, the following group of commands are focused on managing and maintaining Helm releases. The helm status command takes a release name and then displays details about that particular release. Information such as the last deployment date, time of release, the namespace the release was made into, the current revision number, status, and any chart provided notes or instructions which may indicate how to access the running application.
The helm list command displays all of the currently deployed helm releases that exist within the current cluster. For each release, the release name, the namespace into which it was deployed, the current revision number, the date time of the last update, the status, the name of the chart, and the app version are given. When examining the history for a given release, use the helm history command together with the name of the release. Use the previous helm list command to get a list of all of the current release names, then take the one of interest and provide it as an argument to the helm history command. This command will then return a list of revisions for this particular release.
The helm get manifest command takes a release name and will display the entire manifest, end-to-end, required to recreate that particular current release. The helm get manifest command takes a release name and will display the entire manifest, end-to-end, required to recreate the current release. The displayed output contains source comments indicating which template contributed to the manifest segment in question.
Moving on to the final set of commands, those related to creating and packaging your own helm charts. Beginning with the helm create command, use this command to scaffold out a chart directory structure populated with common file examples used to demonstrate and guide you when it comes to building your own custom chart. Once you've run this command, you will typically open up the root chart folder within your IDE or editor of choice and then begin customizing the chart by editing the templates and/or other files within it.
Running the helm template command together with a release name and chart directory will render out all enclosed chart templates locally. This will display the actual cluster resource manifest files that will be submitted to the Kubernetes API service when a helm install command is invoked on the same chart. This command is extremely useful during the chart templating creation process, and allows you to test the helm rendering process locally before installing charts into the cluster.
Next, use the helm package command to package up a specified chart directory. This command packages a chart into a versioned chart tar gzipped archive file, which can then be published into a chart repository.
Finally, the helm lint command takes a path to a chart and then runs a series of tests to verify that the chart is well-formed. The same command without the chart path argument can be called with the root folder of a chart and by doing so will validate the current chart. Any and all encountered errors will be displayed as to the cause and location.
Okay, that completes this lesson. In this lesson, I highlighted the different sets of helm commands that are typically used to manage and maintain charts, releases, and repositories. Understanding which helm commands to use, when and how will help you to become productive with helm. Okay, close this lesson, and I'll see you shortly in the next one.
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.