The Cloud Native Computing Foundation has graduated Karmada, the Kubernetes multi-cluster and multi-cloud orchestration project, marking its move to the highest CNCF maturity tier. The announcement came during KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 in Shanghai and coincided with the release of Karmada v1.19, which adds enhanced multi-component scheduling for AI training jobs and promotes priority-based scheduling to beta by default.
Karmada reaches CNCF’s top maturity level
Graduation is the CNCF’s signal that a project is stable, widely adopted, and ready for production use. For Karmada, the milestone reflects a steady progression through the foundation’s lifecycle: it joined CNCF Sandbox in September 2021 and moved to Incubating in December 2023 before reaching graduation in September 2026.
The project’s timing matters. As more teams run Kubernetes workloads across hybrid cloud environments, regional failover setups, and multiple providers, the need for consistent workload placement has grown. Karmada is designed to address that problem without forcing users to abandon the standard Kubernetes model they already know.
What Karmada is built to do
Karmada, short for “Kubernetes Armada,” is a multi-cluster and multi-cloud orchestration project that extends the Kubernetes API rather than replacing it. That design allows existing manifests, controllers, and tools to continue working on a Karmada control plane without major changes.
According to the project description, the control plane includes three main components: a Karmada API Server, a Karmada Controller Manager, and a Karmada Scheduler. State is backed by its own etcd instance.
Karmada’s goal is to let operators manage one application across multiple clusters as a unified system. That is useful for hybrid cloud deployments, resilience across regions, and avoiding dependence on a single cloud vendor. It is also increasingly relevant for AI workloads, where GPU capacity may be distributed across clouds and regions rather than available in one large cluster.
How placement and customization work
The project uses two custom APIs to describe how workloads should move and how they should be adapted for different clusters:
- PropagationPolicy maps a policy to one or more workloads and defines scheduling and spreading rules. These can include cluster affinity, multi-cluster splitting and rebalancing, and multi-dimensional high availability across region, availability zone, cluster, or provider.
- OverridePolicy lets operators rewrite cluster-specific settings, such as changing container image prefixes by region or selecting different StorageClass values by cloud provider.
That combination is important because multi-cluster management is not only about copying workloads from one place to another. In practice, each cluster may need slightly different configuration, and Karmada aims to handle that variation without changing the original resource template.
Inside the multi-cluster architecture
Karmada’s architecture is built around four controllers that handle propagation from policy to execution. A Cluster Controller manages the lifecycle of registered member clusters. A Policy Controller watches PropagationPolicy objects and binds matching resources into ResourceBinding objects. A Binding Controller turns each ResourceBinding into per-cluster Work objects, and an Execution Controller watches those Work objects and pushes the resulting manifests to each member cluster’s API server.
That workflow gives Karmada a layered model for scheduling and distribution. Policies describe intent, bindings translate that intent into concrete assignments, and execution delivers those assignments to the target clusters. The design is intended to support both steady-state management and more dynamic scheduling decisions, which is especially useful when workloads need to be moved, balanced, or fail over quickly.
The project also exposes Prometheus metrics from its control-plane components and provides Helm charts for installation. Those details matter to operators because they fit into common CNCF deployment and observability tooling rather than requiring a separate stack.
Why the v1.19 release matters
Karmada’s graduation arrived alongside v1.19, which adds enhanced multi-component scheduling for AI training jobs. The release also moves priority-based scheduling to beta and enables it by default.
That emphasis on AI reflects a broader shift in infrastructure planning. GPU resources are often scarce and unevenly distributed, so teams doing distributed training or inference must split workloads across multiple systems. Karmada’s multi-cluster scheduling model is aimed at exactly that kind of environment, where one cluster may not have enough accelerators on its own.
By supporting more flexible placement across clusters and clouds, Karmada positions itself as a control layer for applications that need both scale and resilience. The release suggests the project is continuing to evolve beyond general workload distribution into more specialized scheduling scenarios.
Adoption, contributors, and production use
According to the announcement, Karmada now has more than 1,214 contributors from 292 organizations and more than 5,600 GitHub stars. Its production adopter list includes Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo, WPS, and ZTO.
The reported use cases span hybrid cloud capacity management, cross-region resilience, GPU and CPU scheduling for AI workloads, and fleet-wide configuration distribution. That breadth is part of what helped the project qualify for graduation: CNCF projects at this level are expected to show real-world adoption and a stable operating model.
To reach that milestone, Karmada underwent a third-party security audit. It also formed a formal steering committee, adopted the CNCF Code of Conduct, and maintains a CII Best Practices Badge. Those governance and process steps are a core part of CNCF graduation, not just a formality.
What CNCF sponsors said
Chad Beaudin, the project’s TOC Sponsor, said: “As organizations scale beyond a single Kubernetes cluster, they need consistent management without added complexity. Karmada solves this by extending familiar Kubernetes APIs to work across clusters and clouds.”
Honghui Yue, senior development expert at Trip.com, described the project’s role in production at the company: “At Trip.com, Karmada has become a critical part of our multi-cluster infrastructure and has delivered significant value in production. Without changing existing Kubernetes resource definitions, it has enabled us to operate multiple clusters as a unified resource pool, support cross-cluster elasticity and failover, bring new clusters into production more efficiently, and perform large-scale workload migration with minimal disruption to applications.”
Those comments underline the project’s central appeal: it aims to keep Kubernetes familiar while extending it across many clusters. For teams that already rely on Kubernetes abstractions, that can reduce operational friction compared with more custom or proprietary approaches.
How Karmada compares with other multi-cluster efforts
Karmada is one of two CNCF projects that replaced the retired KubeFed, also known as Federation v2. The other is Open Cluster Management, or OCM, which remains in the Sandbox stage.
OCM uses a hub-and-spoke, agent-based design centered on cluster inventory and add-on APIs. It supports Red Hat Advanced Cluster Management and focuses more on governance and policy distribution. Karmada, by contrast, emphasizes workload placement and dynamic scheduling, and it includes caching layers for cross-cluster resource queries and multi-cluster service discovery.
The article also places Karmada alongside other tools in the broader Kubernetes ecosystem. Cluster API focuses on cluster lifecycle rather than workload placement, while GitOps tools such as Argo CD’s ApplicationSets and Rancher Fleet address application deployment patterns. Microsoft’s KubeFleet, meanwhile, underpins Azure Kubernetes Fleet Manager.
What the graduation means for users
Karmada’s graduation does not change what the project does, but it does signal a higher level of maturity and confidence for operators considering it in production. For teams balancing workload placement across multiple clusters, the project now has the CNCF’s strongest endorsement for stability and adoption.
The practical message is straightforward: if an organization needs to schedule, spread, and adapt Kubernetes workloads across clusters and clouds, Karmada is now established as a graduated CNCF option rather than an emerging one. With v1.19 and the broader adoption base behind it, the project appears to be moving deeper into the category of infrastructure that teams can standardize on for multi-cluster operations.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: September 20, 2026 at 10:33 pm
1 views
