The Kubernetes package manager
Helm — born in 2015 at Deis (later acquired by Microsoft in 2017) — is the package manager for Kubernetes. Helm defines the concept of a chart: a collection of YAML templates that, parameterised with values, generate a coordinated set of K8s manifests (Deployment, Service, Ingress, ConfigMap, Secret, …) to deploy an application.
2.x was the first mainstream release, widely adopted as the de facto standard for Kubernetes application distribution. On 13 November 2019 Helm 3 was released, a major release with architectural redesign.
The Helm 2 flaw: Tiller
The Helm 2 architecture foresaw a server-side component called Tiller — a Kubernetes deployment with cluster-admin permissions. The helm client sent requests to Tiller, which executed operations on the cluster on behalf of the user.
This choice had been criticised from the start for security problems:
- Excessive permissions — Tiller had global privileges even when the user requested limited operations
- Single point of authorisation — authZ hard to granularise per tenant
- RBAC compatibility — Kubernetes RBAC (introduced in 1.6, June 2017) made Tiller problematic in multi-tenant clusters
- Attack surface — Tiller compromise → full cluster access
Helm 3: client-only architecture
Helm 3 removes Tiller completely. The helm client now:
- Authenticates with Kubernetes using the user’s
kubeconfig - Applies the user’s RBAC permissions directly
- Stores release state as Kubernetes Secrets in the deploy namespace
The model is client-only: all operations go through the Kubernetes API like any other kubectl interaction. No privileged component running on the cluster.
Advantages:
- Security — user/namespace/RBAC-based permissions
- Multi-tenant — Helm becomes usable in shared clusters
- Simplicity — one less component to manage
- Isolation — different teams/users can use Helm independently
Other novelties
3-way merge patch
Helm 3 introduces merge logic considering:
- The cluster’s current state
- The last Helm-applied release
- The new release
This solves earlier problems where manual modifications (via kubectl) were overwritten on subsequent Helm upgrade. Now Helm 3 preserves non-conflicting modifications.
OCI registry support
Charts can be hosted in OCI-compliant registries (Docker Hub, Harbor, GCR, Quay, ECR) instead of classic Helm repositories (HTTP). Unifies with the container image registry.
Library charts
New chart type: library chart, for sharing reusable templates across multiple charts without being installable alone.
JSON Schema validation
Chart values can be validated against a declared JSON Schema, with structured errors.
Namespace handling
helm install no longer auto-creates namespaces; requires --create-namespace or existing namespace. Choice consistent with other Kubernetes operations.
Migration from Helm 2
Helm 3 is non backward-compatible on some key dimensions:
- Different release store format (Secrets instead of ConfigMap in kube-system)
- Client does not speak to Tiller
- Some CLI flags rename
The Helm team provides the helm-2to3 plugin to migrate existing releases. The adoption process is:
- Install Helm 3 alongside Helm 2
- Migrate historical releases with
helm 2to3 - Uninstall Tiller
- Remove Helm 2 client
Adoption
At release Helm 3 is adopted by:
- CNCF ecosystem — Helm is an Incubating project since 2018, will become Graduated in 2020
- Chart repositories — Helm Hub (later Artifact Hub) distributes thousands of charts
- Cloud providers — GCP Marketplace, AWS Marketplace publish charts
- Operators integration — hybrid Helm + Operator pattern emerges with Operator SDK
Role in the ecosystem
Helm 3 consolidates a practice: distributing complex Kubernetes applications as versioned packages. Similar to the apt/dnf pattern for Linux but for the Kubernetes domain. Public charts (Artifact Hub in 2024 contains >10,000 charts) allow installing sophisticated applications in one command: PostgreSQL with HA, Redis cluster, Prometheus with Grafana, Istio, ArgoCD, Harbor.
Alternatives
- Kustomize (integrated in kubectl since 1.14) — template-less approach, overlay-based
- Jsonnet (Google) — functional language for generating config
- CDK8s (AWS) — IaC-style in TypeScript/Python for Kubernetes
- Kapitan, Tanka — alternative templating systems
Helm remains dominant for its simplicity and the existing chart ecosystem.
In the Italian context
As of 2019 Helm is widely adopted in Italian DevOps teams that have moved applications to Kubernetes. Helm 2 to Helm 3 migration is gradual but urgently planned by security-sensitive teams: multi-tenant, regulated, PA.
References: Helm 3.0 (13 November 2019). Helm originally at Deis (2015), then Microsoft. Kubernetes RBAC (1.6, June 2017). OCI Image Spec. CNCF Incubating (2018) → Graduated (2020). helm-2to3 migration plugin.