ArgoCD

Fiche express
Type	Outil GitOps de déploiement continu pour Kubernetes
Éditeur	Projet CNCF (initialement Intuit)
Modèle	Pull, réconciliation continue depuis Git
Objet central	CRD Application
Alternative	FluxCD
Voir aussi	Frontière IaC — Terraform, Ansible, GitOps · Terraform — Concepts fondamentaux

ArgoCD est un outil de déploiement continu pour Kubernetes fonctionnant selon le modèle GitOps : l'état désiré des applications est décrit dans un dépôt Git (manifests YAML, Helm charts, Kustomize), et ArgoCD compare en continu cet état désiré à l'état réel du cluster, puis synchronise l'un vers l'autre. Le dépôt Git devient la source de vérité unique ; ArgoCD en est le contrôleur de réconciliation, exécuté in-cluster.

Modèle pull vs déploiement impératif classique

Un pipeline CI classique (Jenkins, GitLab CI/CD) fonctionne en push : à chaque déploiement, il exécute activement kubectl apply ou helm upgrade depuis l'extérieur du cluster, avec des identifiants d'accès au cluster détenus par le pipeline. ArgoCD inverse le flux : un agent pull, déployé dans le cluster lui-même, interroge périodiquement (et via webhook) le dépôt Git et applique lui-même les changements. Aucun identifiant de cluster ne transite par un système externe ; le cluster n'est jamais exposé en écriture à un outil tiers.

<mermaid> flowchart LR

   subgraph Git[Dépôt Git]
     M[Manifests / Helm / Kustomize]
   end
   subgraph Cluster[Cluster Kubernetes]
     A[ArgoCD
controller in-cluster]
     W[(Workloads)]
   end
   M -.pull périodique + webhook.-> A
   A -->|sync : apply du diff| W
   W -.état réel.-> A

</mermaid>

Autre conséquence du modèle pull : le drift (une modification manuelle directe sur le cluster, via kubectl edit par exemple) est détecté en continu et peut être corrigé automatiquement (self-heal), alors qu'un pipeline CI classique ne revérifie l'état qu'au déploiement suivant — le même écart conceptuel que celui documenté pour Terraform/Ansible dans Frontière IaC — Terraform, Ansible, GitOps.

La CRD Application

ArgoCD étend l'API Kubernetes avec une ressource personnalisée Application, qui décrit la source (dépôt, chemin, révision) et la destination (cluster, namespace) d'un déploiement :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mon-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.org/infra/mon-app.git
    targetRevision: main
    path: manifests/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: mon-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

• source — dépôt Git, chemin et révision à surveiller (accepte aussi Helm et Kustomize nativement).
• destination — cluster et namespace cible (ArgoCD peut piloter plusieurs clusters depuis une instance centrale).
• syncPolicy.automated — synchronisation automatique dès qu'un écart est détecté ; prune supprime les ressources retirées du dépôt, selfHeal corrige tout écart introduit hors Git.

Sync manuel vs automatique

Par défaut (sans syncPolicy.automated), ArgoCD détecte le drift et l'affiche (statuts OutOfSync/Synced) mais attend une validation manuelle — via l'interface web ou argocd app sync — avant d'appliquer le changement. C'est le mode privilégié en production le temps de gagner en confiance, avant de bascule vers la synchronisation automatique.

App of Apps

Une Application peut elle-même piloter d'autres Applications, ce qui permet de déclarer tout un cluster (addons, applications métier) depuis une seule racine versionnée dans Git — motif dit « app of apps ». C'est aussi la façon recommandée de finaliser le bootstrap d'un cluster après un provisionnement Terraform : Terraform crée le cluster et installe ArgoCD lui-même (via le provider Helm, en usage minimal — voir Frontière IaC — Terraform, Ansible, GitOps), puis ArgoCD prend le relais pour tout ce qui suit.

Interface et fonctionnalités

• UI web — visualisation en temps réel de l'arbre des ressources d'une application, diffs, historique, rollback en un clic.
• RBAC intégré, SSO (OIDC) pour un contrôle d'accès fin par projet/application.
• Sync waves et hooks — ordonnancement fin de la synchronisation (ex. exécuter un job de migration de base de données avant de déployer la nouvelle version applicative).
• ApplicationSet — génère des Applications à partir d'un modèle, utile pour déployer la même application sur plusieurs clusters ou environnements.

Voir aussi

• FluxCD — alternative GitOps, approche plus modulaire, sans UI imposée
• Frontière IaC — Terraform, Ansible, GitOps — répartition provisionnement/configuration/déploiement
• Terraform — Concepts fondamentaux — provisionnement du cluster en amont
• GitLab CI/CD — orchestration push complémentaire pour le reste du cycle de vie
• Réseau cloud-native — modèle réseau et primitives Kubernetes sur lesquelles ArgoCD déploie