Day 71: Helm rollbacks; Helm vs Kustomize
Helm releases and rollback
Every helm install/upgrade creates a new numbered release revision. Because Helm tracks revision history, rolling back to a known-good state is one command — genuinely useful when a bad chart change (not just a bad image, which Kubernetes rollout already handles) needs undoing.
helm history myapp
helm rollback myapp 3 # back to revision 3Helm vs Kustomize
Kustomize takes a different approach: no templating language at all — you write plain, valid YAML base manifests, then layer "patches" (overlays) on top for each environment, using pure YAML merging rather than a template engine. Helm is more powerful for packaging/distributing reusable charts (with logic, conditionals, dependencies); Kustomize is simpler and avoids the "is this valid YAML or a template?" ambiguity, which is why it's built directly into kubectl (kubectl apply -k).
The honest trade-off
Helm's templating power comes at the cost of readability (a values-heavy chart with loops/conditionals can be hard to reason about just by reading YAML). Kustomize's plain-YAML-plus-patches approach is easier to read but weaker for genuinely reusable, parameterized packages shared across many different consumers.
Key terms
- Helm release
- A tracked, numbered deployment revision of a chart, enabling rollback.
- Kustomize
- A template-free alternative that layers YAML patches over base manifests.
What is the core philosophical difference between Helm and Kustomize?
