GitOps à grande échelle : ArgoCD, Flux et la réalité du terrain

Pourquoi GitOps n'est plus optionnel

Quand votre plateforme dépasse la dizaine de clusters Kubernetes — bord, dev, staging, plusieurs régions de production, clusters clients — le kubectl apply manuel devient un risque opérationnel. GitOps n'est pas une mode : c'est la seule approche qui réconcilie auditabilité (chaque changement est un commit signé), reproductibilité (le cluster est une projection de Git) et vitesse (revert = git revert).

Chez nos clients, deux outils dominent : ArgoCD et Flux v2. Ils partagent les mêmes principes (réconciliation continue, source de vérité Git, support Helm/Kustomize) mais divergent sur la philosophie. Voici un comparatif issu de mises en production réelles.

ArgoCD vs Flux v2 : choisir en connaissance de cause

| Critère | ArgoCD | Flux v2 | |---|---|---| | UX | UI riche, vue topologique | CLI-first, pas d'UI native | | Multi-tenant | Projects + RBAC fin | Tenants via namespaces + Kustomization | | Multi-cluster | Hub-and-spoke (1 ArgoCD → N clusters) | Modèle pull par cluster | | Image automation | ArgoCD Image Updater (séparé) | Image Reflector + Automation natifs | | Empreinte | ~500 Mo RAM en charge | ~150 Mo RAM par contrôleur | | Courbe | Plus rapide à démarrer | Plus modulaire, plus K8s-native |

Notre recommandation : ArgoCD quand les équipes applicatives ont besoin d'une UI partagée, Flux quand vous gérez une flotte hétérogène avec un modèle pull strict (zones air-gapped, edge).

Patterns qui passent à l'échelle

1. ApplicationSets et générateurs de clusters

Déployer la même stack observabilité sur 40 clusters ne doit pas demander 40 manifests. L'ApplicationSet d'ArgoCD avec un générateur clusters résout le problème :

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: platform-observability
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: '{{name}}-observability'
    spec:
      project: platform
      source:
        repoURL: git@github.com:dct/platform.git
        targetRevision: HEAD
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: observability
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Un label env=production sur un nouveau cluster déclenche automatiquement le déploiement complet. Onboarding d'un cluster : minutes au lieu de jours.

2. Operators : au-delà du Helm chart

Un Helm chart décrit un état initial. Un Operator encode le savoir opérationnel : sauvegardes, rolling upgrades, gestion des pannes. Pour les bases de données et systèmes stateful, c'est devenu la norme.

Nos choix de production en 2025 :

• CloudNativePG pour PostgreSQL (failover, PITR, monitoring intégré)
• Strimzi pour Kafka
• Cert-Manager pour les certificats X.509 (DNS-01 avec Let's Encrypt et Route53)
• External Secrets Operator pour synchroniser Vault/AWS Secrets Manager vers K8s

L'Operator SDK et Kubebuilder restent les frameworks de référence pour développer le vôtre, mais avant d'écrire un CRD, vérifiez sur OperatorHub que la roue n'existe pas déjà.

3. Service mesh : utile, mais pas gratuit

Istio s'est simplifié avec le mode ambient (sidecar-less, basé sur ztunnel et waypoints), divisant la consommation mémoire par 3 sur nos benchmarks. Linkerd reste imbattable en simplicité opérationnelle. Cilium Service Mesh mérite un POC sérieux si vous êtes déjà sur Cilium pour le CNI : le plan de données eBPF supprime un saut réseau.

Question à se poser avant l'adoption : avez-vous réellement besoin de mTLS automatique, de traffic shifting fin et d'observabilité L7 partout ? Si la réponse est non sur un cluster, restez avec NetworkPolicy + Cilium.

Sécurité : la checklist de production

Un cluster « par défaut » n'est pas sûr. Notre liste minimale avant tout passage en prod :

• [ ] Pod Security Admission en mode restricted sur tous les namespaces applicatifs
• [ ] CNI avec NetworkPolicy par défaut deny-all (Cilium ou Calico)
• [ ] Images signées avec Cosign et vérifiées par Kyverno ou Sigstore Policy Controller
• [ ] Scan des manifests Git (Checkov, Kubescape) en CI, échec bloquant
• [ ] Aucun secret en clair : External Secrets Operator + Vault/KMS
• [ ] Falco ou Tetragon pour la détection runtime (syscalls, exec inattendus)
• [ ] Audit logs activés et exportés vers un SIEM hors cluster
• [ ] RBAC : interdiction des ClusterRoleBinding à cluster-admin hors break-glass
• [ ] Mise à jour automatique des nodes via Karpenter ou cluster-autoscaler avec drain progressif
• [ ] CIS Benchmark vérifié mensuellement (kube-bench)

Scaling : les vraies limites

Les 5 000 nodes documentés par Kubernetes sont théoriques. En pratique, les murs apparaissent ailleurs :

1. etcd : au-delà de ~8 Go de données, latences imprévisibles. Solution : sharder par cluster plutôt que grossir.
2. API server : les watch coûtent cher. Limitez les controllers tiers et utilisez resourceVersion correctement.
3. Karpenter vs cluster-autoscaler : sur AWS, Karpenter réduit le coût de 20-40 % grâce au bin-packing direct et au choix dynamique du type d'instance.
4. DNS : CoreDNS sature avant le control plane. Activez NodeLocal DNSCache dès 100 nodes.

À retenir

• GitOps n'est pas un outil, c'est un contrat opérationnel : tout passe par Git, sinon le drift gagne.
• ApplicationSet (ArgoCD) ou Kustomization récursive (Flux) sont indispensables au-delà de 5 clusters.
• Les Operators encapsulent le run : préférez CloudNativePG, Strimzi, cert-manager à des Helm charts artisanaux pour le stateful.
• Sécurité par défaut deny-all : PSA restricted, NetworkPolicy, images signées, secrets externalisés — non négociable.
• Scalez par multiplication de clusters, pas par gigantisme : un cluster de 200 nodes bien tenu vaut mieux qu'un monstre de 2 000.