Helm vs Kustomize — choisir son K8s templating

[khalilbenaz]

---

lede: Helm pour packages réutilisables, Kustomize pour overlays simples. Pourquoi pas un seul gagnant, comment les combiner.
lede_en: Helm for reusable packages, Kustomize for simple overlays. Why no single winner, how to combine.
title_en: Helm vs Kustomize — picking your K8s templating

Le besoin

Vous voulez déployer une app Kubernetes dans plusieurs environnements (dev, staging, prod). Comment paramétrer les manifests sans dupliquer ?

Deux approches dominantes : Helm et Kustomize.

Helm — le package manager K8s

Helm template les YAMLs avec des variables :

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

# values.yaml
name: my-app
replicas: 3

helm install my-app . --values values.prod.yaml

Sweet spot : packages réutilisables, charts partagés (Prometheus, Grafana, cert-manager).

Kustomize — overlays sans template

Kustomize utilise overlays au lieu de templates :

# base/deployment.yaml (manifest pur)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1

# overlays/prod/kustomization.yaml
resources:
  - ../../base
patchesStrategicMerge:
  - replicas-patch.yaml

kubectl apply -k overlays/prod

Sweet spot : configs simples, peu de variables. Intégré dans kubectl.

Combiner les deux

Pattern courant : Helm charts pour outils third-party, Kustomize pour vos apps internes.

# Helm pour cert-manager
helm install cert-manager jetstack/cert-manager

# Kustomize pour votre app
kubectl apply -k overlays/prod

Ou Helm + post-render Kustomize pour patches finaux :

helm install my-app . --post-renderer ./kustomize-postrender.sh

Quand préférer Helm

• Distribution de package réutilisable (votre lib pour interne ou public).
• Charts complexes avec beaucoup de paramètres.
• Hooks (pre-install, post-upgrade).

Quand préférer Kustomize

• Vos apps internes (1 app, 3 envs).
• Pas de besoin de packaging réutilisable.
• Pure YAML sans templating Go.

Verdict

Helm + Kustomize coexistent. Helm pour third-party + packages réutilisables. Kustomize pour vos apps. Mix selon contexte.

The need

You want to deploy a Kubernetes app across multiple environments (dev, staging, prod). How to parameterize manifests without duplication?

Two dominant approaches: Helm and Kustomize.

Helm — the K8s package manager

Helm templates YAMLs with variables:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

# values.yaml
name: my-app
replicas: 3

helm install my-app . --values values.prod.yaml

Sweet spot: reusable packages, shared charts (Prometheus, Grafana, cert-manager).

Kustomize — overlays without templating

Kustomize uses overlays instead of templates:

# base/deployment.yaml (pure manifest)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1

# overlays/prod/kustomization.yaml
resources:
  - ../../base
patchesStrategicMerge:
  - replicas-patch.yaml

kubectl apply -k overlays/prod

Sweet spot: simple configs, few variables. Built into kubectl.

Combining both

Common pattern: Helm charts for third-party tools, Kustomize for your internal apps.

# Helm for cert-manager
helm install cert-manager jetstack/cert-manager

# Kustomize for your app
kubectl apply -k overlays/prod

Or Helm + post-render Kustomize for final patches:

helm install my-app . --post-renderer ./kustomize-postrender.sh

When to prefer Helm

• Distribution of reusable package (your lib for internal or public).
• Complex charts with many parameters.
• Hooks (pre-install, post-upgrade).

When to prefer Kustomize

• Your internal apps (1 app, 3 envs).
• No reusable packaging need.
• Pure YAML without Go templating.

Verdict

Helm + Kustomize coexist. Helm for third-party + reusable packages. Kustomize for your apps. Mix per context.

[MikeGarciaAGM]

Implemented and opened PR for this issue: #344

Scope:

• add issue content to posts.json as a new post entry
• preserve existing structure/order