Karmada sort diplômé de la CNCF et fait du multi-cluster Kubernetes une brique de production
Le 8 septembre 2026, la CNCF a annoncé la graduation de Karmada, l’orchestrateur multi-cluster qui déploie une application sur plusieurs clusters sans la modifier. Si vous pilotez trois clusters ou plus, ou préparez une infrastructure multi-cluster pour l’IA, c’est le moment d’évaluer ce passage au statut de projet mature.
8 septembre 2026. La CNCF annonce la graduation de Karmada à KubeCon China, à Shanghai. Novembre 2020. Le premier commit du projet. Décembre 2023. Son passage en statut Incubating. Pourquoi c’est important : le multi-cluster Kubernetes sort du bricolage maison pour devenir une brique auditée, gouvernée et adoptée à grande échelle — au moment précis où les charges d’IA éclatent les parcs de clusters.
Karmada (contraction de Kubernetes Armada) étend l’API standard de Kubernetes avec quatre briques que le cluster unique n’a jamais eues : le placement centralisé, la propagation des ressources, le basculement (failover) et l’autoscaling multi-cluster. L’application, elle, n’est jamais modifiée : elle continue de parler le YAML Kubernetes qu’elle connaît déjà.
Ce que « graduation » veut vraiment dire
La graduation n’est pas une récompense cosmétique. Pour l’atteindre, Karmada a dû passer un audit de sécurité tiers, créer un comité de pilotage (steering committee) pour la gouvernance, adopter le Code of Conduct de la CNCF et maintenir le badge CII Best Practices. En d’autres termes, le projet a démontré la maturité technique et organisationnelle qu’une entreprise exige avant de poser dessus son infrastructure critique.
Les chiffres suivent. Depuis son entrée à la CNCF, Karmada est passé à 1 214 contributeurs issus de 292 organisations, pour plus de 5 600 étoiles GitHub. Le comité de pilotage regroupe des mainteneurs de six organisations, ce qui protège le projet d’une dépendance à un éditeur unique — le point faible classique des forks maison de fédération.
La base d’adoptants est la partie la plus instructive. Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo ou encore DaoCloud l’utilisent en production pour de la capacité hybride, de la résilience multi-région, de la distribution de trafic et du scheduling GPU/CPU pour l’IA. Ce n’est pas une liste de laboratoires : ce sont des plateformes qui facturent de la disponibilité.
Pourquoi le multi-cluster devient une évidence
La raison de fond est démographique. Une organisation commence avec un cluster, puis en ajoute un pour la production, un pour la staging, un par région, un par environnement réglementaire, et soudain elle gère une flotte qu’aucun kubectl ne peut plus embrasser d’un coup. L’IA a accéléré le phénomène : les parcs de GPU vivent rarement dans le même cluster que les microservices, et les jobs d’entraînement distribué doivent se placer là où les accélérateurs sont libres, pas là où le pod est né.
Karmada répond précisément à ce problème avec une politique de propagation (PropagationPolicy) qui décrit, en YAML Kubernetes, où et comment répliquer une charge. Le placement peut se faire par cluster, par région, par contrainte de ressources ou par règle personnalisée. Quand un cluster tombe, la politique de failover redéploie automatiquement la charge vers les clusters restants.
La v1.19, publiée en même temps que la graduation, pousse la logique plus loin avec le scheduling multi-composants pour les jobs d’entraînement IA distribués et la promotion du priority-based scheduling en bêta, activé par défaut. La feuille de route 2026 ajoute la préemption par priorité, la mise en file multi-cluster pour les jobs IA et le support multi-cluster de DRA (Dynamic Resource Allocation) pour les GPU.
La comparaison qui compte
Le réflexe de beaucoup d’équipes a été de construire leur propre fédération avec GitOps — un dépôt, des branches par environnement, des kustomize overlays. Cette approche place des fichiers, mais elle ne planifie pas : elle ne sait pas répondre à « où ce job doit-il tourner pour trouver un GPU libre, et que faire si ce cluster meurt à 3 h du matin ».
Karmada inverse la logique. Au lieu de pousser des fichiers vers des clusters, il expose un point de contrôle unique qui décide du placement, propage la charge, surveille la santé des clusters membres et réagit au basculement. L’intégration native avec Prometheus pour les métriques, etcd pour l’état du plan de contrôle et Helm pour l’installation le rendent compatible avec la chaîne d’outils que les équipes ont déjà.
Il reste une alternative à connaître : les solutions hyperscaler (GKE Fleet, EKS Anywhere, AKS…) et les projets comme OCM ou Liqo qui traitent des facettes voisines. La force de Karmada est son agnosticisme : il orchestre des clusters on-premise, multi-cloud et edge sans exiger un fournisseur commun, ce qui le rend pertinent quand votre stratégie est « ne pas dépendre d’un seul nuage ».
Ce qu’il faut surveiller avant d’adopter
La maturité a un prix en surface cognitive. Karmada ajoute des concepts nouveaux — ResourceTemplate, PropagationPolicy, OverridePolicy, ClusterPropagationPolicy — qu’il faut apprendre et documenter. Une équipe qui n’a jamais été au-delà d’un cluster unique paiera un coût de formation réel avant d’en tirer le moindre bénéfice.
Le second point est l’état des lieux réseau. Orchestrer plusieurs clusters suppose des règles de connectivité inter-cluster propres, une identité de service cohérente et une stratégie de sauvegarde du plan de contrôle central. Karmada simplifie la propagation, pas la plomberie sous-jacente.
Enfin, la base d’adoptants est fortement chinoise — un fait, pas une critique — ce qui signifie que la documentation, les cas d’usage et le rythme de développement portent la marque de ces plateformes. C’est une richesse pour qui cible le multi-région à grande échelle, et un point à vérifier pour qui cherche une intégration avec un écosystème européen ou américain précis.
Verdict
La graduation de Karmada acte une réalité que le terrain connaissait déjà : le cluster unique est devenu l’exception, pas la règle. Si vous pilotez trois clusters ou plus, répartis sur plusieurs régions ou nuages, ou si vous construisez une infrastructure multi-cluster pour l’IA, évaluez Karmada dès maintenant — sa propagation native et son failover automatisé remplacent du code maison difficile à maintenir. Si vous en êtes encore à un ou deux clusters sans projet d’expansion, n’adoptez pas la graduation pour elle-même : le coût d’apprentissage ne se justifie que lorsque la flotte existe. Dans tous les cas, surveillez la v1.19 et le support DRA multi-cluster : c’est là que se jouera la bataille de l’infrastructure IA.