Introduction to Helm
Features of Helm
The course is part of these learning paths
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 give you a quick overview of the architecture as used within Helm. This will be useful to you, as it helps you to understand the different moving parts and how they work collectively together. The good news is that the Helm 3 architecture has been simplified, yet made more secure at the same time. Often, more secure means more complexity. but this is certainly not the case for Helm 3.
Helm 3 uses the following displayed client-only architecture. This architecture, when compared to the previous Helm 2 client server architecture, is both simpler and more secure. Previously, Helm 2 depended on a cluster-hosted component named Tiller. Tiller, configured with a service account in role, needed sufficient permissions to install chart resources into the cluster, potentially across multiple namespaces. The Helm 2 client was designed to communicate through Tiller with Tiller actually performing the duties of resource creation, et cetera.
Now, with Helm 3, this is no longer the case. Instead, the Helm 3 client now communicates directly with the Kubernetes API server. The reason for this change stems mainly from the fact that Kubernetes, as of version 1.16, has RBAC, or role-based access control available and enabled by default. With RBAC, the Helm 3 client can now simply leverage the permissions managed and configured through the standard .kube/config file. This is the same file that the kubectl utility uses to authenticate into the cluster.
So, to be clear, when using the Helm 3 client to deploy a chart into a Kubernetes cluster, the Helm 3 client will authenticate to the cluster using the same credentials stored and managed within the .kube/config file, the same mechanism that kubectl uses. The permissions required to install the various chart resources will be governed by the RBAC permissions configured within the cluster.
Now, before an actual chart installation takes place within a cluster, the chart first needs to be rendered. In Helm 3, this is done client side. The rendering process involves taking each of the templates stored internally within the chart and converting them or rendering them into raw Kubernetes manifest files which the Kubernetes API server understands and can process.
Deploying a Helm chart results in a release being created. When it comes to release management within the cluster, Helm 3 stores release information using Kubernetes Secrets. Previously, Helm 2 used configmaps. Whenever a chart modification takes place, such as creating, upgrading, and/or rollbacks, then this results in a new Kubernetes Secret resource being created within the same Kubernetes namespace in which the actual deployment took place.
Okay, that completes this lesson. In this lesson, I provided you with a brief overview of the underlying Helm 3 architecture and the key differences between Helm 3 and Helm 2. You learnt the Helm 3 uses a simpler architecture and no longer requires the Tiller component. Okay, go ahead and close this lesson, and I'll see you shortly in the next one.
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, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.