Helm Advanced

Helm 2 (deprecated 2020) used Tiller (a server component managing releases in your cluster). Helm 3 (2019+) removed Tiller entirely, storing release metadata in Kubernetes ConfigMaps/Secrets in the same namespace — simpler, more secure, no RBAC nightmare. Migration: `helm 2to3` plugin automates the conversion, or redeploy with Helm 3. All new projects use Helm 3 only. For legacy systems still on Helm 2, prioritize migration as part of your upgrade path.

Helm is a templating engine + package manager: variables, loops, conditionals, chart dependencies, hooks, versioning. Kustomize is a pure declarative patching tool: overlays, generators, patches, no templating. Use Helm for: vendor charts, multi-environment deployments, complex templating, artifact registry. Use Kustomize for: configuration overlays, GitOps with ArgoCD (Kustomize plugin), teams that avoid templates. Modern approach: Helm for charts/packages, Kustomize for environment customization on top. They play well together.

ArgoCD can deploy Helm charts directly: point it at a chart repo + values.yaml, it syncs. Benefits: GitOps-driven (git = source of truth), automatic sync, declarative release management. Pattern: store your values in git, ArgoCD applies them. For multi-cluster: use ArgoCD ApplicationSet with Helm to templated deployments across 10+ clusters. Helm Secrets integrates with ArgoCD to encrypt sensitive values in git. Alternative: Flux Helm Operator (pulls from Helm repo, syncs to cluster).

Helm 3.7+ (2021) added support for storing charts in OCI registries (same as Docker images: Harbor, ECR, Artifactory, GitHub Container Registry). Benefits: single registry for images + charts, lower operational overhead, image scanning tools work on charts too, leverage Docker/Kubernetes infrastructure you already have. Old way: Helm repos (HTTPS, slower, separate tool). New way: `helm pull oci://registry/repo:version`, works like `docker pull`. Enterprise adoption: use Harbor or ECR-hosted charts for better supply-chain security.

Never put secrets in your chart values.yaml — git shouldn't contain passwords. Solutions: (1) helm-secrets: integrates with SOPS (Mozilla) to encrypt sensitive values in git, decrypt at deploy time. (2) External Secrets Operator: pull from Vault/AWS Secrets Manager at runtime. (3) Sealed Secrets: kubeseal encrypts secrets with cluster-specific keys. (4) For CI/CD: inject secrets at deploy time via env vars, not git. GitOps-friendly: helm-secrets + git = encrypted values in source of truth, keys managed separately.

Hooks: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback. Use for: database migrations (run before upgrade), smoke tests (after deploy), cleanup tasks. Example: pre-upgrade hook runs your schema migration, upgrade proceeds. Umbrella (parent) charts: wrap multiple sub-charts (e.g., app chart + postgres + redis) into a single deployment. One `helm install my-release ./umbrella-chart` deploys everything. Benefits: single version, coordinated upgrades, shared values. Downside: less flexibility than installing each separately. Use when: you own all components, want coordinated releases.

Helm is overkill for: (1) single-replica stateless apps (just use kubectl apply). (2) Highly custom per-environment deployments — too many overrides, consider Kustomize instead. (3) Teams uncomfortable with templating — pure YAML + git diffs are clearer. (4) If your chart becomes > 500 lines of templates — refactor into subcharts. (5) Real-time templating at deploy time (compute load, debugging harder than static YAML). If you find yourself writing 20 values-override files per environment, step back: maybe Kustomize layers are clearer, or your chart is doing too much.