Concepts and Architecture — Helm 2 and Helm 3

Docker & Kubernetes · Helm – The Package Manager for Kubernetes · Lesson 2 of 5

A chart is the package, a release is one installation, a repository is where charts are shared; Helm 3 removed Tiller and stores releases in Secrets per namespace.

Concept	Meaning
`helm`	The project and its CLI
Chart	A package of preconfigured Kubernetes resources for an app/tool
Release	One installation of a chart in a cluster; one chart → many releases
Repository	Where charts are stored and shared (HTTP with `index.yaml` or an OCI registry)

flowchart LR
  subgraph H2["Helm 2 (history)"]
    C2["helm CLI"] -- "gRPC" --> T["Tiller (in cluster)"] --> A2["kube-apiserver"]
  end
  subgraph H3["Helm 3"]
    C3["helm CLI + kubeconfig"] --> A3["kube-apiserver"]
    A3 --> S[("Secret sh.helm.release.v1.web.v1")]
  end

Helm 2 (unsupported since 11/2020) used Tiller inside the cluster to render and install charts — usually with cluster-admin rights, a big security hole.

Helm 3 changes:

No Tiller: the CLI uses your kubeconfig, and your own RBAC rights decide what it may do.
Release names are unique per namespace (no longer cluster-wide); release data is stored in Secrets in that namespace.
Three-way merge on upgrade: compares the old chart, the new chart and the live state.
Chart.yaml apiVersion: v2, requirements.yaml merged into Chart.yaml, values checked with JSON Schema, helm serve removed.

Helm 4 has been released (11/2025); the commands in this lesson work as in Helm 3.

Command	Meaning
`helm repo add bitnami https://charts.bitnami.com/bitnami`	Add a repository
`helm search repo nginx`	Search charts in added repos
`helm list -A`	Releases in every namespace

The release lifecycle

Command	Purpose
`helm install web ./mychart -n web`	First installation, revision 1
`helm upgrade --install web ./mychart -n web`	Install if missing, upgrade otherwise; ideal for CI
`helm status web -n web`	Current state and NOTES
`helm get values web -n web`	Values supplied by the user (`--all` adds defaults)
`helm get manifest web -n web`	The exact rendered YAML that was applied
`helm uninstall web -n web`	Delete the release and its objects (`--keep-history` keeps records)

Safer upgrades

--wait makes Helm wait until Deployments, StatefulSets, and Services are ready, and --timeout 5m bounds the wait. --atomic (called --rollback-on-failure in newer releases) rolls back automatically if the upgrade fails, so a broken release does not stay half-applied. --max-history 10 limits how many revision Secrets are kept per release.

Where release data lives

By default each revision is a Secret named sh.helm.release.v1.<release>.v<revision>, holding the chart, values, and manifest compressed. The HELM_DRIVER variable can switch to ConfigMaps or an SQL backend. Because the data lives in the namespace, deleting the namespace removes Helm's history too.

Helm alongside other tools

Tool	Relationship to Helm
Kustomize	Patches plain YAML with overlays; can also post-process Helm output
Helmfile	Declares many releases and their values in one file
Argo CD, Flux	GitOps controllers that render charts from Git or a registry and keep the cluster in sync

In GitOps setups, Argo CD renders the chart itself and applies the result, so helm list may show nothing even though the chart is deployed; check the GitOps tool instead.

Security notes

Helm runs with your kubeconfig, so a chart can create anything your RBAC allows, including ClusterRoles and privileged pods. Read third-party charts with helm template before installing them, and pin chart versions with --version.