In this lesson, you will learn how the Helm architecture evolved to remove the Tiller component, moving from a server-side installation to a client-side, API-driven model.
The Shift from Tiller
In Helm 2, the architecture relied on Tiller, a persistent server-side component running inside your Kubernetes cluster. Tiller acted as the "brain" that received commands from the local Helm CLI, rendered templates, and applied them to the cluster. While functional, this design introduced significant security overhead, as Tiller required high-privilege cluster-admin access to manage resources, creating a potential attack vector.
The Tillerless Architecture
Helm 3 fundamentally changed this by eliminating Tiller entirely. In the current architecture, the Helm CLI acts as a standalone binary that talks directly to the Kubernetes API Server.
When you run helm install or helm upgrade, the Helm client performs the following steps locally:
- It reads your local
~/.kube/configfile to obtain your current cluster credentials. - It performs the template rendering on your local machine.
- It sends the resulting manifest objects directly to the Kubernetes API server using your user's identity.
Because there is no "server" component to maintain, Helm now honors your existing Kubernetes RBAC (Role-Based Access Control) policies. If your local kubeconfig user does not have permission to create a Deployment in a specific namespace, Helm will fail with a standard 403 Forbidden error, just like kubectl would.
Why It Matters
This change simplifies your cluster footprint and security posture. You no longer need to manage Tiller upgrades or worry about securing the communication channel between the CLI and the cluster. Since Helm now runs entirely on your local machine (or within your CI/CD runner's environment), it inherits the security context of the user or ServiceAccount executing the command.
# Helm now communicates directly with the cluster
# No tiller pod required, no "helm init" command needed
helm install my-app ./my-chart --namespace production
Key Takeaway: By removing Tiller, Helm architecture shifted to a client-side model where the CLI uses your existing local credentials to interact directly with the Kubernetes API, streamlining security and eliminating unnecessary cluster-side components.