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.