ArgoCD — Déploiement multi-environnements avec Kustomize

Déployer une application dans un seul environnement est simple. La vraie difficulté commence quand vous gérez dev, staging et production avec des configurations différentes (replicas, ressources CPU/mémoire, URLs, feature flags…). Ce guide vous montre comment structurer votre config-repo avec Kustomize pour ArgoCD et comment automatiser les déploiements multi-clusters avec les ApplicationSet.

Ce que vous allez apprendre

• Comparer les trois stratégies multi-environnements (branches, dossiers, overlays Kustomize)
• Structurer un config-repo avec Kustomize : base commune + overlays par environnement
• Créer un ApplicationSet avec générateur List pour déployer sur plusieurs clusters
• Implémenter un workflow de promotion : dev → staging → production via Pull Request
• Effectuer un rollback ciblé avec git revert sur un environnement sans affecter les autres

Stratégies de gestion multi-environnements

Il existe trois approches pour gérer plusieurs environnements dans Git :

Stratégie	Description	Avantage	Inconvénient
Branches	Une branche par env (dev, staging, main)	Workflow familier	Divergence difficile à gérer, merges complexes
Dossiers	Un dossier par env (envs/dev/, envs/prod/)	Simple	Duplication des manifestes
Kustomize overlays	Base commune + sur-couches par env	Pas de duplication, diff clair	Courbe d’apprentissage

Glissez pour voir

Les overlays Kustomize sont la méthode recommandée. C’est celle décrite dans ce guide.

Structure de dépôt avec Kustomize

config-repo/
└── nginx-demo/
    ├── base/                        # Manifestes communs à tous les envs
    │   ├── kustomization.yaml
    │   ├── deployment.yaml
    │   └── service.yaml
    └── overlays/                    # Sur-couches par environnement
        ├── dev/
        │   ├── kustomization.yaml
        │   └── patch-replicas.yaml  # 1 replica en dev
        ├── staging/
        │   ├── kustomization.yaml
        │   └── patch-replicas.yaml  # 2 replicas en staging
        └── production/
            ├── kustomization.yaml
            ├── patch-replicas.yaml  # 5 replicas en production
            └── patch-resources.yaml # Limites CPU/mémoire plus élevées

La base

La base contient les manifestes partagés, sans valeurs spécifiques à un environnement :

nginx-demo/base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

nginx-demo/base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1    # Valeur par défaut, écrasée dans chaque overlay
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

L’overlay production

nginx-demo/overlays/production/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base   # Hérite de la base
patches:
  - path: patch-replicas.yaml
  - path: patch-resources.yaml
images:
  - name: nginx
    newTag: "1.27.4"   # Version épinglée en production

nginx-demo/overlays/production/patch-replicas.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 5

nginx-demo/overlays/production/patch-resources.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  template:
    spec:
      containers:
        - name: nginx
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: 1000m
              memory: 1Gi

L’overlay dev

nginx-demo/overlays/dev/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - path: patch-replicas.yaml
images:
  - name: nginx
    newTag: "latest"   # Toujours la dernière version en dev

nginx-demo/overlays/dev/patch-replicas.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1

Vérifier localement avant de pousser

# Vérifier ce que Kustomize va générer pour production
kubectl kustomize nginx-demo/overlays/production

# Diff entre dev et production
diff \
  <(kubectl kustomize nginx-demo/overlays/dev) \
  <(kubectl kustomize nginx-demo/overlays/production)

ApplicationSet multi-environnements

Avec Kustomize et la structure overlays, vous pouvez créer un ApplicationSet qui déploie une Application par environnement depuis un seul template :

applicationset-multi-env.yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: nginx-envs
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - env: dev
            namespace: nginx-dev
            cluster: https://kubernetes.default.svc
          - env: staging
            namespace: nginx-staging
            cluster: https://kubernetes.default.svc
          - env: production
            namespace: nginx-production
            cluster: https://prod-cluster.example.com
  template:
    metadata:
      name: "nginx-{{env}}"
    spec:
      project: default
      source:
        repoURL: https://github.com/votre-org/config-repo
        targetRevision: main
        path: "nginx-demo/overlays/{{env}}"
      destination:
        server: "{{cluster}}"
        namespace: "{{namespace}}"
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

Cet ApplicationSet crée trois Applications : nginx-dev, nginx-staging et nginx-production, chacune pointant vers son overlay.

Multi-clusters

Dans l’exemple, prod pointe vers un cluster externe prod-cluster.example.com. Ce cluster doit être enregistré dans ArgoCD au préalable :

argocd cluster add mon-contexte-prod --name prod-cluster

Promotion entre environnements

Via PR (recommandé en production)

La promotion manuelle via Pull Request est la méthode la plus sûre : elle permet une revue humaine avant que le changement n’atteigne la production.

Workflow type :

1. La CI pousse le nouveau tag dans overlays/dev/kustomization.yaml
2. Dev se synchronise automatiquement
3. Après validation, ouvrez une PR pour mettre à jour overlays/staging/
4. Après approbation, mergez. Staging se synchronise
5. Ouvrez une PR vers overlays/production/. Approbation par l’équipe
6. Fusion → déploiement automatique en production

# Script de promotion dev → staging
CURRENT_TAG=$(yq '.images[0].newTag' nginx-demo/overlays/dev/kustomization.yaml)
yq -i ".images[0].newTag = \"${CURRENT_TAG}\"" \
  nginx-demo/overlays/staging/kustomization.yaml
git add nginx-demo/overlays/staging/kustomization.yaml
git commit -m "chore(staging): promote nginx to ${CURRENT_TAG}"
git push origin promote/staging-nginx-${CURRENT_TAG}
# Ouvrir la PR depuis cette branche

Via argocd app sync (dev/staging uniquement)

Pour des environnements non-critiques, vous pouvez forcer une synchronisation depuis la CI après le déploiement en dev :

argocd app sync nginx-staging \
  --server argocd.example.com \
  --auth-token "$ARGOCD_TOKEN" \
  --timeout 120

Rollback

Rollback via ArgoCD (immédiat)

ArgoCD conserve l’historique des synchronisations. Pour revenir à une version précédente :

# Lister l'historique
argocd app history nginx-production

# Revenir à une version précédente (ID visible dans l'historique)
argocd app rollback nginx-production 42

Rollback ArgoCD vs Git revert

La commande argocd app rollback redéploie une ancienne version sans modifier Git. ArgoCD va donc détecter un état OutOfSync (le cluster ne correspond plus à ce que dit Git). En production, préférez le git revert : il crée un nouveau commit, maintient la traçabilité, et ArgoCD se synchronise proprement.

git revert HEAD
git push origin main

À retenir

• Kustomize overlays est la stratégie recommandée pour le multi-env : une base commune + sur-couches spécifiques par environnement. Pas de duplication.
• Un ApplicationSet avec le générateur List permet de déployer la même application dans N environnements depuis un seul template.
• La promotion via PR est la méthode la plus sûre pour la production : revue humaine avant déploiement.
• kubectl kustomize path/ permet de vérifier localement ce que Kustomize générera, avant de pousser.
• Préférez le git revert au argocd app rollback en production pour maintenir Git comme source de vérité.
• Épinglez les versions d’images dans les overlays de production (pas latest).

Prochaines étapes

Sécuriser ArgoCD RBAC, AppProjects, SSO et gestion sécurisée des secrets

App of Apps Gérer des dizaines d'applications depuis une seule Application racine

Intégration CI/CD Connecter votre pipeline CI à ArgoCD

×

📖 Voir la documentation →