Helm 3 Release: Fixing Helm 2’s Flaws and Simplifying Kubernetes Package Management

On November 13, the Helm project announced the first stable Helm 3 release. Although the change set is largely composed of bug fixes for Helm 2, the removal of the Tiller component and a refactored code base (about 80,000 lines changed) transform Helm from a convoluted client‑server tool into a more straightforward command‑line interface.

Why Helm 2 Became Problematic

Helm 2 operated as a client‑server system where the server component, Tiller, performed template rendering, permission checks, and resource management. This design was introduced when Kubernetes lacked features such as ConfigMaps and RBAC, but as the platform matured, Tiller turned into a maintenance burden, leading to frequent errors like “Tiller is down”, unexpected upgrade behavior, and resource conflicts.

Key Issues in Helm 2

Template Engine Limitations: Helm 2 relied on simple text‑templating, which conflicted with YAML’s strict whitespace rules, causing hard‑to‑detect bugs. Complex projects (e.g., kube‑prometheus) often abandoned Helm in favor of tools like Jsonnet or Kustomize.

Hook Handling: Hooks were treated as separate resources, breaking the normal lifecycle and causing problems especially with CRD management.

Resource Conflicts: Users expected Helm to behave like kubectl apply, but Helm 2 frequently produced unresolvable resource conflicts.

What Helm 3 Changes

Helm 3 removes Tiller entirely, making the tool a pure client‑side application that interacts directly with the Kubernetes API server. This eliminates the compatibility layer that caused many of the earlier issues.

Additional improvements include:

Plans to integrate a Lua‑based template engine to provide a more robust and user‑friendly rendering process.

Redesigned hook handling: hooks are now regular resources, and an event model is being introduced (still pending implementation).

Streamlined architecture that reduces the feature set to essentials, making the CLI easier to understand and maintain.

Extended Capabilities Demonstrated by the “Captain” Component

The open‑source “Captain” project, hosted at https://github.com/alauda/captain, serves as the first controller implementation of the Helm 3 proposal. It showcases advanced features such as multi‑cluster deployment, dependency verification, centralized valuesFrom handling, and automated resource‑conflict resolution, illustrating how Helm 3 can be extended for more sophisticated workflows.

Conclusion

Helm 3 represents a significant evolutionary step, turning a historically tangled tool into a cleaner, more stable package manager that aligns with the mature Kubernetes ecosystem. Its simplifications and new extensibility points also position it well against competing solutions like Kustomize, ultimately benefiting users who need reliable, declarative application delivery on Kubernetes.