Cloud / HELM Interview Questions
Explain the core components of Helm architecture: Tiller (v2) vs Helm v3 controller pattern.
The most significant architectural difference between Helm v2 and v3 is the removal of Tiller, the server-side component. Helm v2 architecture consisted of two parts: the Helm client (CLI) and Tiller (server-side component running inside the Kubernetes cluster). Tiller managed releases, tracked deployment history, and executed operations within the cluster. While functional, Tiller had major security drawbacks - it required cluster-admin privileges to function, creating a privileged service account that could modify any resource, which many organizations considered unacceptable for production environments.
Helm v3 completely eliminates Tiller, moving to a client-only architecture with direct Kubernetes API communication through kubeconfig credentials. Each Helm operation (install, upgrade, rollback) now uses the same RBAC permissions as the user executing the command - following the principle of least privilege. Release information that Tiller stored in ConfigMaps/secrets within the cluster is now stored exclusively in Secrets (improved over v2's mixed approach) within the namespace where the release is installed.
The v3 controller pattern introduced several improvements: 1) Three-way strategic merge patch for upgrades (compares current state, previous release state, and user-specified changes); 2) Improved upgrade logic that prevents unnecessary pod restarts; 3) Chart dependencies stored in charts/ directory rather than requirements.yaml; 4) OCI registry support for storing charts in container registries. This client-only architecture makes Helm more secure, simpler to debug, and compatible with standard Kubernetes RBAC workflows.
More Related questions...