GitOps à l'échelle : ArgoCD, Operators et sécurité K8s

Gérer une poignée de clusters Kubernetes est un exercice bien documenté. Passer à 50, 200 ou 1000 clusters, avec des équipes produit autonomes et des exigences de conformité (ISO 27001, DORA, NIS2), change radicalement la donne. Voici les patterns que nous déployons chez nos clients en 2025, et ceux que nous évitons.

GitOps : d'ArgoCD mono-cluster à la fédération

Le pattern app-of-apps a montré ses limites dès qu'on dépasse quelques dizaines d'applications. Le standard de facto aujourd'hui, ce sont les ApplicationSets d'ArgoCD, combinés à des générateurs cluster ou git pour projeter dynamiquement une application sur N clusters.

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

Côté Flux, l'équivalent repose sur les Kustomization + GitRepository avec dépendances explicites (dependsOn). Flux reste préférable quand vous voulez un moteur léger, pilotable par CRD pur, sans UI centrale. ArgoCD gagne dès qu'il y a besoin de visibilité multi-équipes et de RBAC fin via projets.

ArgoCD vs Flux : choix rapide

| Critère | ArgoCD | Flux | |---|---|---| | UI intégrée | Oui, mature | Non (Weave GitOps / Capacitor) | | Multi-tenant RBAC | AppProjects natifs | Par namespace + impersonation | | Dépendances inter-apps | Sync waves | dependsOn explicite | | Empreinte mémoire | ~500 Mo+ | ~150 Mo | | Push-based trigger | Via webhook | Image automation natif |

Operators : quand, et quand pas

Écrire un Operator avec Kubebuilder ou Operator SDK est tentant. En pratique, 80 % des besoins internes se couvrent avec un Helm chart + ArgoCD + un PreSync hook. On ne justifie un Operator maison que si :

• la logique est réellement un automate d'état (reconciliation continue, pas un déploiement one-shot) ;
• il existe des ressources externes à synchroniser (DB managée, topic Kafka, certificat Vault) ;
• le cycle de vie dépasse celui d'un déploiement (backup, failover, rotation de secrets).

Pour tout le reste, privilégier Crossplane avec ses Compositions v2 (stable depuis fin 2024) évite de réinventer un contrôleur. Un CompositeResourceDefinition expose une API propre à vos développeurs (XPostgresInstance, XKafkaTopic) sans qu'une seule ligne de Go soit écrite.

Service mesh : sortir du dogme Istio

Istio en mode ambient (sidecar-less, GA depuis la 1.22) change enfin l'équation coût/bénéfice. Plus de 100 Mo de RAM par pod injecté : les ztunnels par nœud + waypoints optionnels par namespace ramènent la surcharge à un niveau acceptable même sur des clusters de 5000 pods.

Alternatives valables selon le contexte :

• Cilium Service Mesh si vous êtes déjà sur Cilium en CNI (eBPF, pas de sidecar, L7 via Envoy embarqué).
• Linkerd pour la simplicité et une latence p99 difficile à battre.
• Pas de mesh si vous n'avez besoin que de mTLS : SPIRE + une CNI qui gère NetworkPolicies suffit souvent.

Sécurité : le minimum non négociable en 2025

Le CIS Benchmark reste la base, mais ne couvre pas la chaîne d'approvisionnement. Checklist concrète que nous appliquons en audit :

• [ ] Pod Security Admission en mode restricted sur tous les namespaces applicatifs (plus de PSP depuis 1.25).
• [ ] Kyverno ou OPA Gatekeeper pour les policies qui dépassent PSA (registres autorisés, labels obligatoires, ressources limites).
• [ ] Signatures d'images vérifiées avec Cosign + policy verify-images Kyverno.
• [ ] SBOM générés à la CI (Syft) et scannés (Trivy, Grype) avec seuil bloquant sur les CVE critiques.
• [ ] Secrets jamais en clair dans Git : External Secrets Operator + Vault / AWS Secrets Manager.
• [ ] Falco ou Tetragon pour la détection runtime (appels syscall suspects, exec dans pod).
• [ ] Rotation automatique des certificats du control plane et des kubelets (--rotate-certificates).
• [ ] Audit log envoyé à un SIEM, avec règles sur exec, portforward, modifications de ClusterRoleBinding.

Scaler au-delà des limites par défaut

Un cluster EKS/GKE standard plafonne en pratique autour de 500 nœuds avant que l'etcd et l'API server ne deviennent le goulet. Quelques leviers éprouvés :

1. Karpenter plutôt que Cluster Autoscaler : provisioning en 30-60 s au lieu de 3-5 min, et consolidation continue des nœuds.
2. Priority & Fairness bien configuré sur l'API server — sinon un contrôleur bavard suffit à étrangler le cluster.
3. etcd dédié sur SSD NVMe avec --quota-backend-bytes=8589934592 au minimum pour les gros clusters.
4. Fragmenter horizontalement : plusieurs clusters de 300-500 nœuds valent mieux qu'un cluster de 2000. Le coût opérationnel d'ArgoCD multi-cluster est inférieur au coût d'un incident etcd.
5. Virtual Kubelet / Karmada pour la fédération si vous avez besoin d'un vrai plan de contrôle global.

À retenir

• ApplicationSets + générateur cluster est le pattern GitOps par défaut au-delà de 10 clusters ; pas besoin de réinventer une surcouche.
• N'écrivez un Operator que si la logique est un vrai automate d'état. Pour le reste, Crossplane ou Helm suffisent.
• Istio ambient ou Cilium Service Mesh rendent le mesh acceptable en coût ; remettez le sujet à plat si votre décision date d'avant 2024.
• La sécurité K8s 2025 se joue sur la supply chain : Cosign, SBOM, Kyverno et détection runtime (Falco/Tetragon) sont non négociables.
• Préférez plusieurs clusters de taille moyenne pilotés par GitOps à un monstre unique : le plafond pratique d'etcd vous rattrapera toujours.