Helm Fundamentals

Charts, Releases, Repositories

Helm is Kubernetes' package manager. A chart is a directory of templated manifests plus default values.yaml; a release is one installed instance with a name; a repository is an HTTPS index of packaged charts (.tgz).

Helm 3 removed Tiller — there is no in-cluster agent. On helm install, the CLI renders templates, talks straight to the API server, and records the release (manifests + supplied values, base64) in a Secret named sh.helm.release.v1.<name>.v<revision> in the release namespace. Rollback = re-apply a previous revision's stored manifest from those Secrets.

Everyday Commands

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-api bitnami/nginx -n prod --create-namespace \
  -f values-prod.yaml --set replicaCount=3
helm upgrade --install my-api bitnami/nginx -n prod --atomic --wait
helm list -n prod
helm status my-api -n prod
helm get values my-api -n prod        # user-supplied values only
helm template my-api bitnami/nginx -f values-prod.yaml > rendered.yaml
helm uninstall my-api -n prod

Value precedence: --set beats -f files, which beat the chart's defaults. --atomic pairs --wait with automatic rollback when an upgrade fails — the default safety net for unattended installs.

Pitfalls and Interview Angles

Unpinned versions. helm install foo bitnami/nginx resolves to whatever is latest today. Pin --version (and image tags) so tomorrow's deploy matches today's test.

Secrets in values. Release Secrets live in etcd holding your values — base64 is not encryption. Use SOPS/Sealed Secrets or external secret managers for anything sensitive.

History growth. Every upgrade stores a new Secret revision; prune old ones only with eyes on rollback needs.

--set on CLI. Visible in shell history and process lists — pass sensitive values via files.

Interview angle: explain exactly where release state lives, how helm rollback works from that state, and what you pin to make a deploy reproducible.