Helm vs Kustomize

K8s configs.

Overview

Helm and Kustomize are the two leading Kubernetes configuration tools with very different mental models. Helm is a package manager (templated YAML, values files, chart registries, release-management semantics); Kustomize is overlay-based (plain Kubernetes YAML with strategic-merge patches, no templating language, built into kubectl). The right answer depends on whether package distribution or template-free overlays matter more.

• Helm: package manager. Templated YAML, values files, chart registries. Default for distributing third-party operators and reusable packages.
• Kustomize: overlay-based. Plain YAML with strategic-merge patches, no templating language. Default for first-party config that varies across environments.
• Operational fit per team. Existing Helm chart investment biases toward continuity; teams that find Helm templating opaque bias toward Kustomize.
• Per-cluster choice. Different clusters may pick differently. Document the rationale per cluster.

The approach

Workload-driven choice, per-team operational fit considered, documented rationale per cluster. The discipline is making the config tool choice once with a written reason rather than maintaining duplicate config in both tools (which is operationally toxic).

• Workload-driven. Tool per cluster. Reality drives the answer.
• Helm for package distribution. Third-party operators, reusable packages, multi-customer deployments. Default when chart distribution matters.
• Kustomize for first-party env overlays. Same base YAML across dev/staging/prod with strategic-merge patches. Default when templating-free YAML matters.
• Operational fit plus documented rationale. Team workflow considered; per-cluster rationale captured. Future migrations have a paper trail.

Why this compounds

The right config tool compounds across years. Manifest patterns and team expertise align with the tool; cross-cluster tooling (CI integration, drift detection, deploy automation) gets built once and reused. By year two the tool choice is automatic per cluster.

• Better operational fit. Tool matches team. Velocity stays high.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Better engineering velocity. Right tool means manifests compose cleanly. Iteration speed increases.
• Year-one investment, year-two habit. First tool choice is the investment; subsequent clusters inherit the patterns.