Helm & Templating
How you actually generate Kubernetes manifests in 2026.
The contenders
- ★ Helm — chart-based templating; the de-facto standard despite the Go-template-in-YAML pain. Default because every operator / piece of OSS infra ships a Helm chart.
- ★ Kustomize — overlay-based; bundled into kubectl. Patch base manifests for env-specific values without templating.
- Helmfile — declarative wrapper around Helm; manage many releases as code.
- kapp (Carvel) — apply-based deploy with diffing + change detection.
- ytt (Carvel) — YAML templating via Starlark / overlays; cleaner than Go templates.
- jsonnet — Google-derived templating language; powerful, niche.
- Tanka (Grafana) — jsonnet-based deployment tool.
- cdk8s — write k8s manifests in TypeScript / Python / Java / Go.
- Pulumi Kubernetes provider — same idea via Pulumi.
Helm vs. Kustomize
Both ship in production. Common pattern:
- Helm for vendor charts (ingress-nginx, cert-manager, kube-prometheus-stack, etc.).
- Kustomize for your own apps (no templating, just overlays per env).
- Both at once — Helm to render, Kustomize to overlay; supported via
helm template | kustomize buildor Argo CD's combined mode.
Helm chart hosting
- ★ Helm chart in your app's git repo — most flexible.
- Helm OCI registries (any OCI registry — GHCR, Harbor, ECR, etc.) — official since Helm 3.8.
- Artifact Hub — search / discover public charts.
- Bitnami charts — broad library; check license / maintenance.
Patterns to know
- ★ Pin chart versions in your IaC / Argo App. Auto-upgrades break clusters.
- Render to disk + commit is sometimes nice for diff review (Argo "GitOps with rendered manifests").
values.yamlper environment. Don't conditional-everything inside templates.- Test charts with
helm template+kubeval/kube-conform/kube-linter. - Avoid post-render hacks when possible; use a proper overlay (Kustomize / ytt) instead.
- Subcharts vs. dependencies — keep your Chart.yaml lean; don't bundle 12 sub-charts.
Linting / validation
- kubeconform — fast manifest validator against k8s schemas.
- kube-linter (StackRox / Red Hat) — best-practice / security checks on manifests.
- datree — policy-as-code for k8s manifests.
- OPA / Conftest — policy testing.
When Helm is wrong
- For your own simple app: a Kustomize overlay is usually enough. The Helm complexity tax doesn't pay off.
- For complex composition / dependencies: Pulumi or cdk8s gives you a real programming language.
Pick this if…
- Vendor / OSS deploys: Helm (no choice).
- Your own app, minimal templating: Kustomize.
- TS / typed manifests: cdk8s or Pulumi.
- Manage many Helm releases declaratively: Helmfile or Argo CD ApplicationSet.
- Carvel ecosystem: ytt + kapp.