Helm
Charts, releases, values, K8s package management.
Theory
Helm is the package manager for Kubernetes. A Helm chart is a collection of Kubernetes YAML templates (Deployment, Service, ConfigMap, etc.) parameterized with Go templating. Instead of maintaining 10 separate YAML files per application, you define one chart and override values per environment. helm install, helm upgrade, and helm rollback manage releases.
Chart structure: Chart.yaml (metadata — name, version, appVersion), values.yaml (default configuration values), templates/ (YAML templates using {{ .Values.xxx }} syntax), charts/ (sub-chart dependencies), NOTES.txt (post-install instructions). helm create my-app scaffolds this structure. The chart version and appVersion are separate: chart version tracks chart changes, appVersion tracks the app being deployed.
Values: helm install my-release ./my-chart uses values.yaml defaults. Override with --values prod-values.yaml (file) or --set image.tag=v1.2.3 (inline). Multiple --values files are merged left-to-right. Environment-specific values files (values-dev.yaml, values-prod.yaml) parameterize the same chart for each environment. Never put secrets in values files — use external-secrets or sealed-secrets.
Templating: {{ .Values.image.repository }}:{{ .Values.image.tag }} renders to your image reference. Helper templates in _helpers.tpl define reusable snippets (app labels, selector labels) via {{ define "myapp.labels" }}. {{ include "myapp.labels" . }} inserts them. The "." is the current context — pass it to include for access to .Values and .Release.
Releases and history: every helm install creates a release. helm upgrade my-release ./chart applies changes and creates a new revision. helm history my-release shows all revisions with status. helm rollback my-release 3 rolls back to revision 3. Release metadata is stored as Kubernetes Secrets in the target namespace — helm status and helm get work across cluster restarts.
Chart repositories: helm repo add bitnami https://charts.bitnami.com/bitnami; helm search repo postgresql finds available charts. OCI registries (ghcr.io, ECR) are the modern alternative to HTTP chart repos. helm pull downloads a chart tarball for inspection before deployment. ArtifactHub.io catalogs public Helm charts with security scores and provenance info.
Hooks: Helm hooks run Jobs at specific lifecycle points — pre-install (run DB migrations before new pods start), post-install (smoke test after deploy), pre-delete (backup before teardown). Hooks are Kubernetes resources annotated with helm.sh/hook: pre-upgrade. Hook weights control execution order when multiple hooks exist at the same stage.
Architecture Diagram
Users / clients
|
Helm
|
Core services
|
Data + observabilityExamples
# Helm
# Charts, releases, values, K8s package management.
# Validate in staging before production rollout.Interview Questions
What problem does Helm solve?
It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.
Key components of Helm?
Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.
Common production pitfalls?
Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.
How do you test changes safely?
Staging parity, canary/gradual rollout, automated health checks, and documented rollback.
Metrics to prove success?
Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.
Beginner vs advanced concern?
Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.
Best Practices
- Treat Helm config as code with review and CI validation.
- Define SLOs and dashboards before production cutover.
- Document rollback and ownership for on-call.
- Use least privilege for credentials.
Common Mistakes
- Adopting Helm without measurable success criteria.
- No staging environment mirroring production constraints.
- Missing rollback path during incidents.
- Undocumented on-call expectations.
Cheat Sheet
Practical Exercises
Stand up Helm locally or in free tier; document commands and failure recovery.
Introduce misconfiguration; practice detection and rollback under time limit.