Karmada graduates from the CNCF and turns multi-cluster Kubernetes into a production building block
On September 8, 2026, the CNCF announced the graduation of Karmada, the multi-cluster orchestrator that runs an application across several clusters without modifying it. If you operate three or more clusters, or are building multi-cluster infrastructure for AI, this is the moment to evaluate the move to a mature, audited project.
September 8, 2026. The CNCF announces the graduation of Karmada at KubeCon China in Shanghai. November 2020. The project’s first commit. December 2023. Its promotion to Incubating status. Why it matters: multi-cluster Kubernetes is leaving homegrown territory to become an audited, governed, and widely adopted building block — just as AI workloads are fragmenting cluster fleets.
Karmada (short for Kubernetes Armada) extends the standard Kubernetes API with four capabilities a single cluster never had: centralized placement, resource propagation, failover, and multi-cluster autoscaling. The application itself is never touched: it keeps speaking the Kubernetes YAML it already knows.
What “graduation” actually means
Graduation is not a cosmetic award. To earn it, Karmada had to pass a third-party security audit, establish a formal steering committee for governance, adopt the CNCF Code of Conduct, and maintain the CII Best Practices badge. In short, the project demonstrated the technical and organizational maturity an enterprise requires before trusting it with critical infrastructure.
The numbers follow. Since joining the CNCF, Karmada has grown to 1,214 contributors across 292 organizations and more than 5,600 GitHub stars. The steering committee spans maintainers from six organizations, which protects the project from the single-vendor dependency that plagues homegrown federation forks.
The adopter base is the most instructive part. Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo, and DaoCloud run it in production for hybrid capacity, multi-region resilience, traffic distribution, and GPU/CPU scheduling for AI. This is not a list of labs — these are platforms that sell availability.
Why multi-cluster is becoming a given
The underlying reason is demographic. An organization starts with one cluster, then adds one for production, one for staging, one per region, one per regulatory environment, and suddenly it runs a fleet no single kubectl can embrace at a glance. AI has accelerated the shift: GPU pools rarely live in the same cluster as microservices, and distributed training jobs need to land wherever accelerators are free — not wherever the pod happened to be born.
Karmada answers exactly this with a PropagationPolicy that describes, in Kubernetes YAML, where and how to replicate a workload. Placement can be driven by cluster, by region, by resource constraint, or by a custom rule. When a cluster fails, the failover policy redeploys the workload to the surviving clusters automatically.
v1.19, shipped alongside the graduation, pushes the logic further with multi-component scheduling for distributed AI training jobs and the promotion of priority-based scheduling to beta, enabled by default. The 2026 roadmap adds priority-based preemption, multi-cluster queuing for AI jobs, and multi-cluster support for DRA (Dynamic Resource Allocation) across GPUs.
The comparison that matters
The reflex for many teams has been to build their own federation with GitOps — one repository, branches per environment, kustomize overlays. That approach places files, but it does not schedule: it cannot answer “where should this job run to find a free GPU, and what happens if that cluster dies at 3 a.m.?”
Karmada inverts the logic. Instead of pushing files at clusters, it exposes a single control point that decides placement, propagates the workload, watches member-cluster health, and reacts to failover. Native integration with Prometheus for metrics, etcd for control-plane state, and Helm for installation keeps it compatible with the toolchain teams already have.
One alternative is worth naming: the hyperscaler offerings (GKE Fleet, EKS Anywhere, AKS…) and sibling projects like OCM or Liqo that address neighboring facets. Karmada’s strength is its agnosticism: it orchestrates on-premise, multi-cloud, and edge clusters without requiring a common vendor, which makes it relevant when your strategy is “do not depend on a single cloud.”
What to watch before adopting
Maturity comes at a cognitive cost. Karmada introduces new concepts — ResourceTemplate, PropagationPolicy, OverridePolicy, ClusterPropagationPolicy — that have to be learned and documented. A team that has never gone beyond one cluster will pay a real training cost before extracting any benefit.
The second point is the network footing. Orchestrating several clusters assumes clean inter-cluster connectivity, a coherent service identity, and a backup strategy for the central control plane. Karmada simplifies propagation, not the plumbing underneath.
Finally, the adopter base is heavily Chinese — a fact, not a criticism — which means the documentation, use cases, and development cadence carry the imprint of those platforms. That is an asset for anyone targeting multi-region scale, and something to verify for anyone seeking tight integration with a specific European or American ecosystem.
Verdict
Karmada’s graduation formalizes a reality the field already knew: the single cluster has become the exception, not the rule. If you run three or more clusters across regions or clouds, or are building multi-cluster infrastructure for AI, evaluate Karmada now — its native propagation and automated failover replace homegrown code that is painful to maintain. If you are still at one or two clusters with no expansion plan, do not adopt graduation for its own sake: the learning curve only pays off once the fleet exists. Either way, watch v1.19 and the multi-cluster DRA support — that is where the battle for AI infrastructure will be fought.