Kustomize : gérer facilement ses environnements Kubernetes (exemple simple Dev/Prod)

Quand on déploie des applications sur Kubernetes, on se retrouve très vite avec plusieurs environnements : développement, préproduction, production… Et souvent, les manifests YAML se ressemblent à 95 %.
Résultat : beaucoup de copier-coller, et autant de risques d’erreurs.

👉 C’est exactement le problème que Kustomize résout.

Qu’est-ce que Kustomize ?

Kustomize est un outil intégré à kubectl qui permet de :

• Définir une base commune (déploiement, service, configmaps…)
• Créer des overlays (patchs) pour chaque environnement, sans dupliquer tous les YAML
• Gérer simplement les variations (ex : debug activé en dev, scaling en prod)

Pas besoin de templating compliqué : tout reste du YAML natif.

Exemple : une app simple (Nginx hello-world)

Imaginons que nous ayons une petite application web.
On veut :

• En dev → 1 pod, debug activé, ressources limitées.
• En prod → plusieurs pods pour absorber la charge.

1. La base commune

k8s/base/deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: web
        image: nginxdemos/hello:latest
        ports:
        - containerPort: 80
        env:
        - name: DEBUG
          value: "false"

k8s/base/service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  selector:
    app: demo-app
  ports:
  - port: 80
    targetPort: 80

k8s/base/kustomization.yaml :

resources:
  - deployment.yaml
  - service.yaml

2. Overlay pour le dev

k8s/overlays/dev/kustomization.yaml :

resources:
  - ../../base
patchesStrategicMerge:
  - patch-dev.yaml

k8s/overlays/dev/patch-dev.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  template:
    spec:
      containers:
      - name: web
        env:
        - name: DEBUG
          value: "true"
        resources:
          requests:
            cpu: "100m"
            memory: "64Mi"
          limits:
            cpu: "250m"
            memory: "128Mi"

3. Overlay pour la prod

k8s/overlays/prod/kustomization.yaml :

resources:
  - ../../base
patchesStrategicMerge:
  - patch-prod.yaml

k8s/overlays/prod/patch-prod.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 3

4. Déploiement

• Pour déployer en dev :

kubectl apply -k k8s/overlays/dev

• Pour déployer en prod :

kubectl apply -k k8s/overlays/prod

Résultat 🎉

• Dev : 1 pod, DEBUG activé, ressources limitées → idéal pour tester localement sans tout casser.
• Prod : 3 pods, scalés → prêt à encaisser la charge en production.

Pourquoi c’est puissant ?

• Moins de YAML dupliqué : la base est commune.
• Plus de lisibilité : les patchs ne montrent que ce qui change.
• Évolutif : facile d’ajouter un nouvel environnement (staging, tests E2E…).

🐻‍❄️ Chez PG3, on recommande souvent Kustomize comme première étape avant d’aller vers du GitOps (ArgoCD ou FluxCD), car il garde les choses simples et claires.