8 min de lecture

Le Kubernetes multi-cluster est aujourd’hui une réalité pour la plupart des équipes plateforme, mais il est rarement bien organisé. Trois, quatre, parfois sept clusters se répartissent entre régions cloud, sites edge et environnements on-premise dédiés. Ce qui commence comme un argument de résilience finit trop souvent par créer un second silo opérationnel : des politiques fédérées ici, des corrections manuelles des dérives là. La question n’est plus de savoir s’il faut du multi-cluster, mais combien de romantisme technologique l’exploitation peut encore supporter.

Les points clés en bref

• Le multi-cluster est un modèle opérationnel, pas un choix d’outillage : Qui introduit Argo CD, Cluster API ou Karmada sans avoir au préalable défini la propriété, la garde opérationnelle et la source des politiques construit un second silo opérationnel à côté du premier. C’est l’ordre qui décide, pas la pile technologique.
• La fédération évolue, les plans de contrôle centralisés mobilisent du personnel : Karmada et vCluster traitent les dérives différemment. La fédération répartit la complexité, le modèle centralisé la concentre. Les deux approches fonctionnent, mais une seule convient à la taille donnée d’une équipe.
• GitOps est la seule source de politique évolutible : Dès que l’on dépasse trois clusters, toute action manuelle via kubectl devient un risque d’anomalie en audit. Argo CD ou Flux avec le motif App-of-Apps rend visible le problème de dérive avant qu’il ne devienne coûteux.

En lienPlatform Engineering, sans détour  /  Multi-cloud sans détours

Pourquoi un cluster en devient trois, sans qu’on l’ait décidé

L’histoire est la même dans presque toutes les équipes plateforme. Tout commence avec un cluster de production par environnement, complété par une configuration de reprise après sinistre (DR) dans une deuxième région. Puis arrive un site edge avec des exigences strictes de latence, un tenant isolé pour des raisons réglementaires dans le secteur financier, un pool GPU dédié pour les charges de travail IA. Personne n’a officiellement opté pour le multi-cluster. C’est arrivé comme ça.

La rupture se produit généralement à deux endroits : la configuration Ingress et la gestion RBAC. Les deux sont définis par cluster, et dérivent plus vite qu’on ne peut les corriger. Ces derniers trimestres, les équipes plateforme rapportent systématiquement le même schéma : la charge de travail n’augmente pas linéairement avec le nombre de clusters, mais plutôt selon un facteur 1,7 par cluster supplémentaire, car les permutations croissent plus vite que les charges applicatives.

Le cloud hybride n’est pas un modèle d’architecture, c’est la conséquence de deux équipes qui n’ont pas parlé à temps. Le multi-cluster en est la prochaine étape.

Les jalons : comment se construit typiquement une pile multi-cluster

Qui souhaite évaluer le niveau de maturité de son parcours multi-cluster peut s’orienter selon cette frise chronologique. Elle n’est pas normative, mais décrit le chemin que la plupart des équipes plateformes parcourent en deux à trois ans.

Fédération, plan de contrôle centralisé ou vCluster : le tableau honnête des compromis

Trois architectures s’affrontent pour le fonctionnement multi-cluster. Elles ne s’excluent pas mutuellement, mais évoluent selon des dimensions différentes. Choisir la mauvaise voie, c’est construire précisément le silo opérationnel qu’on cherchait à éviter.

Ce tableau reflète la réalité, pas les promesses marketing. Karmada est solide, mais la diversité des opérateurs dans les entreprises DACH est suffisamment grande pour qu’une seule CRD récalcitrante fasse échouer toute la fédération. OCM et RHACM offrent un support fournisseur, ce qui compte en audit, mais signifie aussi, au quotidien, qu’on doit d’abord consulter Red Hat avant de corriger un problème. vCluster est élégant, mais ne remplace pas des clusters réels – qui l’oublie s’en rend compte au plus tard lors du premier problème de volume persistant.

Les trois chiffres que toute équipe plateforme doit connaître

Dans un environnement multi-cluster, trois métriques sont indispensables : sans elles, toute discussion sur le modèle opérationnel reste théorique. Elles sont inconfortables, car elles semblent au premier abord représenter des coûts supplémentaires. En réalité, elles sont la seule chose qui rende l’exploitation pilotable.

Ces chiffres proviennent d’expériences vécues par des équipes plateforme, pas d’une étude. Celui qui ne les mesure pas dans son propre environnement ne dispose d’aucune base de discussion face au CFO lorsque l’investissement dans la plateforme doit être justifié.

Qui possède réellement la plateforme quand elle est décentralisée ?

La question organisationnelle est la plus délicate. Dans un environnement mono-cluster, le propriétaire de la plateforme est évident. Dans un environnement multi-cluster, la propriété devient un sujet de négociation. Les équipes tenant (tenants) veulent une autonomie locale, l’équipe plateforme souhaite des politiques centralisées, et le service sécurité exige un point unique d’audit. Ces trois attentes ne sont pas contradictoires, mais elles sont rarement explicitées.

Un modèle opérationnel solide nécessite trois décisions claires avant même le choix d’une technologie. Premièrement : qui décide dans quel cluster un workload est déployé ? Deuxièmement : qui est en charge de quels clusters, et qui assume les conséquences d’un incident critique (Sev-1) ? Troisièmement : quelles politiques sont négociables selon les tenants, et lesquelles sont immuables ? Ces questions ne peuvent être résolues par un outil, mais uniquement par une décision humaine.

La différence entre une plateforme multi-cluster efficace et un second silo opérationnel n’est pas le choix entre Karmada et OCM. Elle tient à la présence ou non de ces trois décisions formalisées, et au fait que l’équipe puisse encore les reconnaître un an plus tard.

À quoi ressemble un parcours réaliste sur 90 jours

Les équipes plateforme qui gèrent aujourd’hui trois clusters ou plus et souhaitent consolider leur modèle opérationnel multi-cluster trouvent généralement une réponse solide en 90 jours. Il ne s’agit pas de finaliser la pile technologique, mais de poser les décisions qui suivront.

Les 30 premiers jours sont consacrés à un inventaire honnête : combien de clusters existent réellement, qui possède des kubeconfigs avec accès, quel est l’âge du Helm Release le plus ancien, toujours en fonction depuis des mois. Cet inventaire révèle souvent plus qu’un atelier d’architecture. Les 30 jours suivants visent la consolidation GitOps, idéalement via Argo CD App-of-Apps ou des arbres Kustomization Flux. Celui qui échoue ici ne devrait pas encore songer à la fédération. Les 30 derniers jours sont dédiés à la question du modèle opérationnel : hub-and-spoke ou véritable fédération, et surtout — quelle équipe sera encore présente dans deux ans pour maintenir cette pile ?

Ce programme n’a rien d’élégant. Mais c’est ce qui fonctionne quand on considère la plateforme multi-cluster non pas comme une prouesse architecturale, mais comme un engagement opérationnel.

Foire aux questions

À partir de quand Karmada ou OCM deviennent-ils plus intéressants qu’une fédération Argo CD simple ?

En pratique, à partir de cinq clusters de production ou au plus tard en cas d’exigences strictes en matière de multi-tenancy. Argo CD seul permet de déployer des charges de travail dans plusieurs clusters, mais n’offre aucune logique de répartition des charges. Karmada permet des politiques de répartition déclaratives, tandis qu’OCM inclut un reporting de politiques au format audit. En dessous de cinq clusters, le surcoût opérationnel de ces deux outils n’est que rarement justifié.

Quelle est la source de dérive la plus fréquente en exploitation multi-cluster ?

Les interventions d’urgence via kubectl qui ne sont pas répercutées dans le dépôt Git. Dès qu’un incident critique (Sev-1) doit être résolu rapidement, l’accès direct au cluster l’emporte. Si ces cas ne sont pas systématiquement documentés a posteriori, une dérive s’accumule, souvent invisible jusqu’au prochain sinistre. Une solution consiste à fournir aux ingénieurs des kubeconfigs en lecture seule et à instaurer une procédure « break-glass » ciblée pour les cas Sev-1.

Les vCluster remplacent-ils les clusters réels ?

Non. Les vCluster offrent une isolation au niveau de l’API pour les tenants, mais partagent le noyau hôte, le réseau et le stockage persistant. Ils sont très efficaces pour les environnements de développement et de préproduction. Toutefois, pour la production réglementée ou une véritable résilience multi-région, des clusters dédiés restent obligatoires.

Où s’inscrivent les outils de politique-as-code comme OPA Gatekeeper et Kyverno dans les architectures multi-cluster ?

Les deux outils fonctionnent par cluster, mais le bundle de politiques doit être déployé depuis une source unique, sinon l’incohérence que l’architecture cherche à éviter réapparaît. Idéalement, GitOps déploie les manifestes de politique dans chaque cluster, et un outil centralisé de reporting, comme l’API Policy Report, agrège les violations. Celui qui maintient manuellement les politiques par cluster se retrouve avec le problème d’audit qu’il souhaitait justement éviter.

Quel est le piège le plus coûteux et le plus caché en multi-cluster ?

Le trafic réseau inter-cluster et l’egress d’observabilité. Le trafic inter-région d’un service mesh ou d’une plateforme Loki centralisée peut alourdir la facture cloud plus vite que les coûts des clusters eux-mêmes. Une analyse réseau préalable avant la décision de fédération permet d’éviter par la suite des refontes coûteuses.

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image