Karmada, gradué CNCF : le multi-cluster Kubernetes a mûri

Deux clusters Kubernetes, ça se gère encore à coups de contextes kubectl et de scripts bash. À partir de cinq ou six, avec des équipes différentes qui déploient dessus et des contraintes de placement (proximité GPU, région, conformité), le bricolage s’effondre. C’est le problème que Karmada attaque de front, et le projet vient de franchir une étape qui change la donne côté crédibilité : la graduation CNCF, annoncée le 7 septembre 2026.

Pour resituer : la CNCF classe ses projets en trois étages — Sandbox, Incubating, Graduated. Graduated, c’est le niveau que Kubernetes lui-même, Prometheus ou Envoy ont atteint : audit de sécurité tiers indépendant passé, gouvernance formalisée avec un comité de direction, adoption du code de conduite CNCF, badge CII Best Practices actif. Ce n’est pas une formalité administrative — c’est la garantie qu’un projet ne dépend plus d’un seul contributeur ou d’une seule entreprise, et qu’il a survécu à un audit externe sur sa sécurité.

Ce que fait vraiment Karmada

Karmada (« Kubernetes Armada ») étend l’API Kubernetes standard plutôt que de la remplacer. Concrètement, tes manifests, tes contrôleurs et tes outils existants fonctionnent sans modification sur un control plane Karmada — c’est le point de différenciation qu’ils mettent en avant, et c’est ce qui change la donne comparé à une solution qui t’obligerait à réécrire tes déploiements dans un format propriétaire.

Le control plane repose sur quatre briques : un karmada-apiserver, un karmada-controller-manager, un karmada-scheduler, et une instance etcd dédiée, isolée de celle de tes clusters membres. Par-dessus, quatre contrôleurs orchestrent la propagation des ressources : Cluster Controller, Policy Controller, Binding Controller et Execution Controller.

PropagationPolicy et OverridePolicy : les deux API qui font le travail

Deux CRD custom portent toute la logique métier :

• PropagationPolicy associe une politique à un ensemble de charges de travail (relation 1:n) et définit les contraintes de placement et de répartition.
• OverridePolicy permet de réécrire une configuration spécifiquement pour tel ou tel cluster — utile quand un cluster de prod a des limites de ressources différentes d’un cluster de dev, par exemple.

Un exemple minimal pour distribuer un déploiement nginx sur deux clusters membres :

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2

Tu peux créer la ressource et la policy dans n’importe quel ordre — Karmada rattrape la propagation dès que les deux existent. C’est un détail, mais ça évite les race conditions bêtes dans un pipeline CI/CD qui applique du YAML en parallèle.

Installer Karmada : compter cinq minutes, pas une journée

La commande d’installation la plus directe passe par le plugin kubectl :

kubectl karmada init

La documentation officielle annonce environ cinq minutes pour que tous les composants soient prêts dans le namespace karmada-system. Une installation via Helm est disponible aussi, pour les équipes qui préfèrent tout garder dans un chart versionné plutôt que d’exécuter une commande interactive.

Ensuite, joindre un cluster membre se fait selon deux modes. En mode push, depuis le control plane, avec le kubeconfig du cluster à joindre :

kubectl karmada join ${MEMBER_CLUSTER_NAME} --cluster-kubeconfig=$HOME/.kube/config

Ou en mode pull, depuis le cluster membre lui-même, ce qui évite de faire transiter un kubeconfig complet vers le control plane :

kubectl karmada register 172.18.0.3:32443 --token [token] --discovery-token-ca-cert-hash [hash]

Le mode pull est clairement préférable dès que tes clusters membres appartiennent à des équipes ou des environnements réseau distincts : tu n’as pas besoin de centraliser des identifiants d’accès à chaque cluster dans le control plane Karmada.

Karmada vs les alternatives : pas de solution universelle

Le multi-cluster n’a pas un seul bon outil, il a plusieurs outils pour plusieurs problèmes différents, et Karmada ne prétend pas tout couvrir :

• Cluster API gère le cycle de vie des clusters eux-mêmes (créer, mettre à jour, détruire) — pas le placement des charges de travail dessus. Les deux se complètent plutôt qu’ils ne s’opposent.
• Argo CD ApplicationSets ou Rancher Fleet déploient le même manifeste sur plusieurs clusters via une approche GitOps déclarative. C’est plus simple à adopter si ton besoin, c’est « le même état partout », mais tu n’as pas de scheduler dynamique qui décide où placer une charge selon la capacité ou la priorité au runtime.
• Open Cluster Management (OCM) propose une architecture hub-and-spoke centrée sur l’inventaire de clusters. Le projet reste en phase Sandbox CNCF, donc à un niveau de maturité clairement inférieur à Karmada aujourd’hui.
• KubeFleet / Azure Fleet Manager est l’option native Microsoft si tu es full-Azure avec plusieurs clusters AKS. Elle s’intègre mieux à l’écosystème Azure (RBAC, Azure Policy), mais elle t’enferme dans ce fournisseur — pas d’option pour orchestrer un cluster GCP ou on-prem à côté.

Si ton besoin réel est du placement dynamique (répartir une charge selon la capacité GPU disponible, la latence réseau, ou une contrainte de priorité) et que tu veux rester agnostique du fournisseur cloud, Karmada est clairement le bon choix aujourd’hui — c’est littéralement le problème pour lequel il a été conçu. Si tu es mono-cloud Azure et que ton besoin se limite à synchroniser le même état sur trois clusters AKS, Fleet Manager ou même Argo CD ApplicationSets suffiront très bien, avec beaucoup moins de composants à opérer.

L’adoption, en chiffres

Le projet revendique plus de 1214 contributeurs issus de 292 organisations et 5600 étoiles sur GitHub. Côté production, Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, Kuaishou, SenseTime et Vivo figurent parmi les adoptants cités. C’est une base plus large que la plupart des projets qui sortent tout juste d’Incubating — et ça pèse dans la décision d’un audit de sécurité : plus il y a d’implémentations réelles qui remontent des bugs, plus vite les trous se bouchent.

La version 1.19, sortie en même temps que l’annonce de graduation, ajoute une amélioration de la planification multi-composants pensée pour les charges IA, et fait passer la planification basée sur les priorités en beta. Un signal cohérent avec ce qu’on voit ailleurs dans l’écosystème Kubernetes en ce moment — la pression des charges GPU/IA pousse tous les schedulers, y compris multi-cluster, à devenir plus fins sur la priorisation.

FAQ

Karmada a-t-il un intérêt pour deux clusters seulement ?

Rarement. La valeur de Karmada vient du scheduling dynamique et des politiques de répartition à l’échelle. Pour deux clusters, la complexité opérationnelle d’un control plane et d’un etcd dédiés supplémentaires dépasse probablement le bénéfice — un script ou de l’ApplicationSets Argo CD fera l’affaire.

Le control plane Karmada est-il un point de défaillance unique ?

Il faut le traiter comme tel et le durcir en conséquence — etcd dédié à sauvegarder, accès API à restreindre. Une panne du control plane Karmada n’arrête pas les workloads déjà déployés sur les clusters membres (ils continuent de tourner normalement), mais elle bloque toute nouvelle propagation ou mise à jour de policy tant qu’elle n’est pas résolue.

Quelle version de Kubernetes faut-il sur les clusters membres ?

Karmada s’appuie sur les API Kubernetes standard côté membres, donc toute version supportée en amont convient en pratique. Vérifie la matrice de compatibilité officielle avant une mise à niveau majeure, en particulier si tu mélanges des membres sur des versions très éloignées les unes des autres.

Et maintenant ?

Si tu gères déjà plusieurs clusters à la main et que tu sens que ça devient ingérable, la graduation CNCF est un bon moment pour retester Karmada sérieusement — le badge de maturité lève une bonne partie des objections classiques côté sécurité et gouvernance qu’on entend en revue d’architecture. Commence petit : un control plane Karmada avec deux clusters de test, une PropagationPolicy simple, et regarde comment ton équipe s’approprie le modèle avant de l’étendre à la prod.

Si le sujet qui te bloque aujourd’hui, c’est plutôt la sécurité d’un cluster unique avant même de penser au multi-cluster, notre guide complet pour sécuriser un cluster Kubernetes reste la base à poser en premier. Et si ta contrainte de placement concerne spécifiquement des GPU, notre article sur la Dynamic Resource Allocation se combine bien avec du scheduling multi-cluster Karmada pour répartir les charges IA là où la capacité existe réellement.