Sign in Subscribe
ArgoCD

ArgoCD 3.0 : GitOps multi-tenant et progressive delivery pour Kubernetes

Jean-Michel Helem

• 10 min read
ArgoCD 3.0 : GitOps multi-tenant et progressive delivery pour Kubernetes

ArgoCD 3.0, sorti en janvier 2026, marque la maturité du GitOps sur Kubernetes. Multi-tenancy natif sans hacks RBAC complexes, progressive delivery intégrée (canary, blue-green), ApplicationSets v2 pour gérer 1000+ applications, et reconciliation 3x plus rapide. Si vous utilisez encore ArgoCD 2.x ou déployez manuellement avec kubectl, cette mise à jour change la donne.

$2

Les problèmes résolus

ArgoCD 2.x souffrait de limitations qui rendaient son usage complexe à grande échelle :

Multi-tenancy bricolé : partager un cluster ArgoCD entre plusieurs équipes nécessitait des RBAC manuels complexes. Chaque équipe voyait toutes les applications. La segmentation était fragile et sujette aux erreurs.

Pas de progressive delivery : déployer une nouvelle version en production signifiait un remplacement immédiat (recreate) ou un rolling update basique. Pas de canary natif, pas de validation automatique, pas de rollback intelligent.

ApplicationSets limités : générer des applications pour 100 clusters nécessitait des templates complexes. Pas de conditions dynamiques, pas de templating avancé.

Performance médiocre : avec 500+ applications, la reconciliation prenait 5-10 minutes. Le dashboard devenait inutilisable. Les syncs parallèles saturaient l'API server Kubernetes.

ArgoCD 3.0 résout structurellement ces problèmes. Ce n'est pas juste des features ajoutées, c'est une refonte architecturale.

Les nouveautés majeures

Multi-tenancy Projects 2.0 : isolation native par projet avec quotas, RBAC granulaire, et visibilité limitée. Une équipe ne voit que ses applications. Fini les hacks.

Argo Rollouts intégré : progressive delivery (canary, blue-green) directement dans ArgoCD sans outil séparé. Validation automatique avec métriques Prometheus.

ApplicationSets v2 : templating puissant avec conditions, boucles, fonctions. Gérer 1000 applications sur 100 clusters avec un seul manifest.

Performance 3x : reconciliation parallélisée intelligemment, cache Redis optimisé, requêtes API Kubernetes batchées. 1500 applications se synchronisent en 2 minutes.

Diff 3-way amélioré : détection précise des drifts, ignorance des champs managed par Kubernetes (status, metadata.generation), moins de faux positifs.

Notifications v2 : webhooks riches (Slack, Teams, PagerDuty) avec contexte complet (diff, logs, metrics). Templates personnalisables.

$2

Installation fresh ArgoCD 3.0

Pour une nouvelle installation sur Kubernetes 1.28+ :

# Créer le namespace
kubectl create namespace argocd

# Installer ArgoCD 3.0 (manifest officiel)
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/v3.0.0/manifests/install.yaml

# Patcher le service pour LoadBalancer (optionnel)
kubectl patch svc argocd-server -n argocd -p \
  '{"spec": {"type": "LoadBalancer"}}'

Le mot de passe initial est généré aléatoirement. Changez-le immédiatement après première connexion.

Migration depuis ArgoCD 2.x

La migration 2.x → 3.0 est backwards-compatible mais nécessite quelques ajustements :

1. Backup complet :

# Exporter toutes les applications
kubectl get applications -n argocd -o yaml > apps-backup.yaml

# Exporter les AppProjects
kubectl get appprojects -n argocd -o yaml > projects-backup.yaml

2. Mise à jour :

# Remplacer les CRDs (Custom Resource Definitions)
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.0.0/manifests/crds/

# Mettre à jour ArgoCD
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/v3.0.0/manifests/install.yaml

3. Valider :

# Vérifier la version
argocd version

# Lister les applications (doivent toutes être présentes)
argocd app list

Si des applications sont OutOfSync après migration, c'est normal. ArgoCD 3.0 détecte mieux les drifts. Faites un sync manuel.

$2

Créer des projets isolés

Projects 2.0 introduit une isolation stricte par équipe :

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-frontend
  namespace: argocd
spec:
  description: Applications Frontend Team

# Isolation : seuls les membres du groupe peuvent voir/gérer
  roles:
    - name: developer
      groups:
        - team-frontend-devs
      policies:
        - p, proj:team-frontend:developer, applications, get, team-frontend/*, allow
        - p, proj:team-frontend:developer, applications, sync, team-frontend/*, allow

- name: admin
      groups:
        - team-frontend-admins
      policies:
        - p, proj:team-frontend:admin, applications, *, team-frontend/*, allow

# Quotas par projet (nouveauté 3.0)
  quotas:
    maxApplications: 50
    maxSyncConcurrency: 5
    maxResourcesPerApp:
      cpu: "4"
      memory: "8Gi"

# Restrictions sur les destinations
  destinations:
    - namespace: 'frontend-*'
      server: https://kubernetes.default.svc
    - namespace: 'staging-frontend-*'
      server: https://staging-cluster

# Restrictions sur les sources Git
  sourceRepos:
    - https://github.com/company/frontend-apps
    - https://github.com/company/shared-charts

# Ressources Kubernetes autorisées
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

Les quotas évitent qu'une équipe monopolise ArgoCD. maxSyncConcurrency: 5 garantit que l'équipe ne sync pas plus de 5 apps simultanément, préservant les ressources pour les autres.

RBAC granulaire

Intégration avec votre IdP (Okta, Azure AD, Google Workspace) :

# argocd-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  # SSO avec Google (exemple)
  url: https://argocd.company.com
  dex.config: |
    connectors:
      - type: google
        id: google
        name: Google
        config:
          clientID: $GOOGLE_CLIENT_ID
          clientSecret: $GOOGLE_CLIENT_SECRET
          redirectURI: https://argocd.company.com/api/dex/callback
          hostedDomains:
            - company.com

# Mapper les groupes Google aux rôles ArgoCD
  policy.csv: |
    # Admins platform
    g, platform-admins@company.com, role:admin

# Team frontend
    g, team-frontend-devs@company.com, proj:team-frontend:developer
    g, team-frontend-admins@company.com, proj:team-frontend:admin

Avec cette config, chaque équipe ne voit que ses applications dans le dashboard ArgoCD. Plus de pollution visuelle, plus de risque de modifier l'application d'une autre équipe.

$2

Configuration Canary

ArgoCD 3.0 intègre Argo Rollouts. Voici un déploiement canary progressif :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      # Étapes de déploiement canary
      steps:
        - setWeight: 10    # 10% du trafic vers la nouvelle version
        - pause: {duration: 2m}  # Observer 2 minutes

- setWeight: 25
        - pause: {duration: 2m}

- setWeight: 50
        - pause: {duration: 5m}

- setWeight: 75
        - pause: {duration: 5m}

# Validation automatique avec métriques
      analysis:
        templates:
          - templateName: success-rate
        args:
          - name: service-name
            value: myapp

# Rollback automatique si métriques KO
      abortScaleDownDelaySeconds: 30

# Service mesh integration (Istio)
      trafficRouting:
        istio:
          virtualService:
            name: myapp
            routes:
              - primary

selector:
    matchLabels:
      app: myapp

AnalysisTemplate pour validation

Validation automatique basée sur Prometheus :

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: service-name

metrics:
    # Métrique 1 : Success rate HTTP
    - name: success-rate
      interval: 1m
      successCondition: result[0] >= 0.95  # 95% minimum
      failureLimit: 3  # Échoue après 3 mesures mauvaises
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}",
              status=~"2.."
            }[2m])) /
            sum(rate(http_requests_total{
              service="{{args.service-name}}"
            }[2m]))

# Métrique 2 : Latence p95
    - name: latency-p95
      interval: 1m
      successCondition: result[0] <= 500  # <500ms
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            histogram_quantile(0.95,
              rate(http_request_duration_seconds_bucket{
                service="{{args.service-name}}"
              }[2m])
            ) * 1000

Si une seule métrique échoue 3 fois, le rollout est automatiquement aborté et la version précédente est restaurée. Zero intervention humaine.

Blue-Green deployment

Alternative au canary : basculement instantané avec validation :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp-bluegreen
spec:
  replicas: 5
  strategy:
    blueGreen:
      # Service actif (production)
      activeService: myapp-active

# Service preview (pré-production)
      previewService: myapp-preview

# Auto-promotion après validation
      autoPromotionEnabled: false
      autoPromotionSeconds: 300  # 5 minutes

# Tests de smoke avant promotion
      prePromotionAnalysis:
        templates:
          - templateName: smoke-tests

La version blue (ancienne) reste disponible 10 minutes après promotion. Si un problème est détecté, rollback instantané en rebasculant le service.

Pour intégrer cela dans votre pipeline CI/CD, consultez notre guide CI/CD avec GitHub Actions.

$2

Generator List amélioré

Déployer la même application sur 100 clusters :

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-multicluster
spec:
  generators:
    - list:
        elements:
          - cluster: prod-us-east
            url: https://prod-us-east.k8s.company.com
            region: us-east-1
            env: production
            replicas: "10"

- cluster: prod-eu-west
            url: https://prod-eu-west.k8s.company.com
            region: eu-west-1
            env: production
            replicas: "8"

- cluster: staging-us
            url: https://staging-us.k8s.company.com
            region: us-east-1
            env: staging
            replicas: "3"

template:
    metadata:
      name: 'myapp-{{cluster}}'
    spec:
      project: team-backend
      source:
        repoURL: https://github.com/company/myapp
        targetRevision: HEAD
        path: helm
        helm:
          parameters:
            - name: replicaCount
              value: '{{replicas}}'
            - name: environment
              value: '{{env}}'
            - name: region
              value: '{{region}}'

destination:
        server: '{{url}}'
        namespace: myapp

Un seul manifest génère 100 applications ArgoCD, une par cluster. Modifications du manifest = mise à jour automatique de toutes les apps.

Generator Git avec conditions

ApplicationSets v2 supporte les conditions dynamiques :

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: microservices-monorepo
spec:
  generators:
    - git:
        repoURL: https://github.com/company/microservices
        revision: main
        directories:
          - path: services/*

# Conditions (nouveauté 3.0)
        template:
          metadata:
            name: '{{path.basename}}'
          spec:
            # Déployer uniquement si le service a un Chart.yaml
            conditions:
              - path: '{{path}}/Chart.yaml'
                exists: true

# Variables extraites du chemin
            project: '{{path.segments[1]}}'  # services/team-X/app

source:
              repoURL: https://github.com/company/microservices
              targetRevision: main
              path: '{{path}}'

Chaque nouveau dossier dans services/* avec un Chart.yaml crée automatiquement une application ArgoCD. Supprimez le dossier, l'application est supprimée (si prune: true).

Generator Matrix (combinaisons)

Combiner plusieurs generators (nouveauté 3.0) :

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: apps-cross-product
spec:
  generators:
    - matrix:
        generators:
          # Tous les clusters
          - list:
              elements:
                - name: prod-1
                  url: https://prod-1.k8s
                - name: prod-2
                  url: https://prod-2.k8s
                - name: staging
                  url: https://staging.k8s

# Toutes les apps du repo
          - git:
              repoURL: https://github.com/company/apps
              revision: main
              directories:
                - path: apps/*

Ce generator crée une application pour chaque combinaison (app, cluster). 10 apps × 3 clusters = 30 applications générées automatiquement.

$2

Reconciliation parallèle

ArgoCD 3.0 parallélise intelligemment la reconciliation :

# argocd-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  # Nombre de workers de reconciliation (défaut: 10, max: 50)
  application.reconciliation.workers: "30"

# Intervalle de reconciliation (défaut: 3m)
  timeout.reconciliation: "180s"

# Batch size pour les requêtes Kubernetes
  kube.batch.size: "50"

Avec 30 workers, ArgoCD peut synchroniser 30 applications simultanément. Sur un cluster avec 1000 apps, la reconciliation complète passe de 30 minutes (ArgoCD 2.x, 10 workers) à 10 minutes (ArgoCD 3.0, 30 workers).

Sharding du controller

Pour >2000 applications, shardez le controller :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: argocd-application-controller
spec:
  replicas: 3  # 3 shards
  template:
    spec:
      containers:
        - name: argocd-application-controller
          env:
            # Activer le sharding
            - name: ARGOCD_CONTROLLER_REPLICAS
              value: "3"
            - name: ARGOCD_CONTROLLER_SHARD
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name

Chaque shard gère 1/3 des applications. Avec 3 shards, vous pouvez gérer 6000 applications sans dégradation de performance.

Optimisation diff

Le diff 3-way ignore désormais les champs Kubernetes automatiques :

# argocd-cm ConfigMap
data:
  resource.customizations: |
    # Ignorer les champs gérés par Kubernetes
    apps/Deployment:
      ignoreDifferences: |
        jsonPointers:
          - /status
          - /metadata/generation
          - /metadata/resourceVersion

Résultat : -80% de faux positifs sur les drifts détectés. ArgoCD ne vous alerte plus pour des changements non significatifs.

$2

Webhooks Slack enrichis

Notifications avec contexte complet :

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token

template.app-deployed: |
    message: |
      Application {{.app.metadata.name}} deployed successfully!

🎯 Environment: {{.app.spec.destination.namespace}}
      🔗 Repo: {{.app.spec.source.repoURL}}
      📝 Revision: {{.app.status.sync.revision}}
      ⏱️ Sync duration: {{.app.status.operationState.finishedAt | since .app.status.operationState.startedAt}}

📊 Changes:
      {{range .app.status.sync.syncResult.resources}}
      - {{.kind}}/{{.name}}: {{.hookPhase}} ({{.status}})
      {{end}}

🔍 View in ArgoCD
    slack:
      attachments: |
        [{
          "color": "good",
          "title": "Deployment successful",
          "title_link": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}"
        }]

template.app-health-degraded: |
    message: |
      ⚠️ Application {{.app.metadata.name}} is DEGRADED!

Reason: {{.app.status.health.message}}

🔍 Investigate
    slack:
      attachments: |
        [{
          "color": "danger",
          "title": "Health degraded - action required",
          "title_link": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}"
        }]

trigger.on-deployed: |
    - when: app.status.operationState.phase in ['Succeeded']
      send: [app-deployed]

PagerDuty pour incidents critiques

Escalade automatique vers PagerDuty :

data:
  service.pagerduty: |
    token: $pagerduty-token

template.app-sync-failed-critical: |
    pagerduty:
      severity: critical
      summary: "ArgoCD sync failed for {{.app.metadata.name}}"
      details: |
        Application: {{.app.metadata.name}}
        Project: {{.app.spec.project}}
        Error: {{.app.status.operationState.message}}

Sync qui échoue en production = incident PagerDuty créé automatiquement avec toutes les infos pour déboguer.

$2

App of Apps pattern

Gérer un cluster entier avec une seule application root :

# root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://github.com/company/cluster-config
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Le repo contient des manifests d'applications ArgoCD :

cluster-config/
├── apps/
│   ├── infrastructure/
│   │   ├── cert-manager.yaml
│   │   ├── ingress-nginx.yaml
│   │   └── prometheus.yaml
│   ├── backend/
│   │   ├── api-gateway.yaml
│   │   ├── user-service.yaml
│   │   └── order-service.yaml
│   └── frontend/
│       └── web-app.yaml

Modifier un fichier YAML dans le repo = ArgoCD détecte, crée/met à jour/supprime l'application correspondante. Tout le cluster est codifié dans Git.

Waves pour orchestration

Déployer dans un ordre précis avec waves :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: database
  annotations:
    argocd.argoproj.io/sync-wave: "1"  # Déployée en premier
spec:
  # ... config database
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-api
  annotations:
    argocd.argoproj.io/sync-wave: "2"  # Après la database
spec:
  # ... config backend
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend
  annotations:
    argocd.argoproj.io/sync-wave: "3"  # En dernier
spec:
  # ... config frontend

ArgoCD attend que la wave 1 soit Healthy avant de déployer la wave 2. Garantit que la DB est prête avant de démarrer le backend.

$2

Métriques Prometheus

ArgoCD 3.0 expose des métriques riches :

# ServiceMonitor pour Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-metrics
  namespace: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-metrics
  endpoints:
    - port: metrics

Métriques clés à alerter :

  • argocd_app_sync_total{phase="Failed"} : syncs échoués
  • argocd_app_health_status{health_status="Degraded"} : apps dégradées
  • argocd_app_reconcile_duration_seconds : durée de reconciliation
  • argocd_redis_request_duration_seconds : latence Redis

Dashboard Grafana

Importez le dashboard officiel ArgoCD (ID 14584) dans Grafana pour visualiser :

  • Santé des applications (healthy, progressing, degraded)
  • Historique des syncs (succès/échecs)
  • Temps de reconciliation par application
  • Utilisation des ressources (CPU, RAM du controller)

Pour une observabilité complète, intégrez avec OpenTelemetry comme décrit dans notre guide Observabilité en production.

$2

Least privilege RBAC

Ne donnez jamais role:admin aux développeurs :

# AppProject avec permissions minimales
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-backend
spec:
  roles:
    - name: developer
      policies:
        # Lire toutes les apps du projet
        - p, proj:team-backend:developer, applications, get, team-backend/*, allow

# Sync uniquement (pas delete, pas update du manifest)
        - p, proj:team-backend:developer, applications, sync, team-backend/*, allow

# Voir les logs
        - p, proj:team-backend:developer, logs, get, team-backend/*, allow

Les devs peuvent sync (déployer) mais pas modifier les manifests ArgoCD ni supprimer des apps. Seuls les tech leads ont ces droits.

Secrets externes

Ne committez jamais de secrets dans Git. Utilisez External Secrets Operator :

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: database/prod/password

ArgoCD déploie l'ExternalSecret, qui lui-même fetch le secret depuis Vault. Le secret réel n'est jamais dans Git.

Audit logs

Activez les audit logs pour tracer qui a fait quoi :

# argocd-cm ConfigMap
data:
  admin.enabled: "true"

# Logger tous les changements
  server.log.level: "info"

Forwarding vers votre SIEM (Splunk, Datadog, Elasticsearch) pour analyse de sécurité.

$2

$2

ArgoCD 3.0 transforme GitOps de proof-of-concept en solution enterprise-grade. Multi-tenancy natif, progressive delivery intégrée, ApplicationSets v2 pour gérer 1000+ applications, performance 3x améliorée.

Si vous déployez encore manuellement avec kubectl ou utilisez des scripts CI/CD fragiles, ArgoCD 3.0 est le moment de migrer vers GitOps. Si vous êtes sur ArgoCD 2.x, la migration vers 3.0 est backwards-compatible et apporte des gains immédiats.

Les équipes platform qui maîtrisent ArgoCD 3.0 + Argo Rollouts + ApplicationSets sont très recherchées en 2026. C'est la stack GitOps de référence pour Kubernetes.

Commencez par un cluster de test, déployez quelques applications, expérimentez avec les progressive deployments. GitOps n'est pas juste une méthodologie, c'est un changement culturel : Git devient la source de vérité, Kubernetes converge vers Git, les drifts sont détectés et corrigés automatiquement.

L'avenir du déploiement Kubernetes est déclaratif, auditable, et automatisé. ArgoCD 3.0 le rend accessible à tous.