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 support@cloudacademy.com.
Learning Objectives
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
Intended Audience
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
Prerequisites
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.
Resources
Welcome back. In this lesson, I'm going to introduce you to Helm and review its background, what motivated its creation, the terminology associated with it, and when and where you should consider using it yourself. To begin with, Helm is an application package manager for Kubernetes. So what, and why do I need one, you may be asking yourself. I'm already familiar with kubectl and I know I can use that to create resources in the cluster and it works.
Therefore, why do I need to consider using Helm? Well, it turns out, for large and intricate deployments, Helm can be used to simplify and enhance the deployment experience. How so, you're now probably wondering. Well, let's first consider life before Helm came onto the scene. Kubernetes, as we know, is an open source cluster-based system used to schedule and orchestrate containerized applications. A containerized application is normally composed of multiple Kubernetes resources. For example, consider a simple three-tiered based application, consisting of a front end, application, and database tiers. Deploying this into Kubernetes could be accomplished by deploying several resources, such as a deployment, configmap, and service resource for each tier. Each required resource will be typically codified into its own manifest file. All manifest files are typically secured and version controlled to ensure that we have a verifiable and auditable record of change, knowing for sure what gets deployed into our cluster.
Now, when it comes to deployment time, we need to execute the kubectl apply
command multiple times, one for each of our manifest files. Now, this becomes problematic since we need to run the kubectl
command each time for each individual resource. This is not only labor intensive, but also error prone.
Dependencies can be forgotten or perhaps the installation sequence is incorrectly performed, all of which requires rework and effort to fix and remediate. We also need to consider the limitations of working directly with manifest files themselves. For example, manifests don't facilitate parametrization. This often leads to manifest proliferation to accommodate small environmental changes. Manifests don't provide any functionality to wire into the application deployment lifecycle hooks. Often, you will want to do some external activity either just before or just after a resource has created within the cluster. And there really isn't a decent native way to manage and maintain a history of revisions for a related set of manifest files within Kubernetes. Enter Helm.
Helm was originally introduced to simply and enhance the Kubernetes cluster deployment experience. Helm uses the concept of a chart, which is in essence a package containing all of the related parts for a specific cluster deployment. Helm can be used to deploy applications that consist of many resources with a single command.
Helm takes care of deploying the chart and its individual resources, all in the correct sequenced order, and ensures that the final deployment outcome is a fully functioning application. There's definitely a lot more to Helm and I'll dive deeper as the course progresses, but this should give you a good idea of the space that Helm plays in. Okay, that completes this lesson. In this lesson, I introduced you to some of the pain points involved when working with Kubernetes manifest files and for which Helm fixes for us.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).