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.