Karmada, short for Kubernetes Armada, is a multi-cluster orchestration system. Teams apply ordinary Kubernetes resources, such as a Deployment, to the Karmada control plane, and policies decide which member clusters receive them, how many replicas each gets, and what changes per cluster. It addresses the sprawl that follows from running many clusters across regions, clouds and edge sites: without a coordinating layer, every cluster is deployed, scaled and repaired separately. Karmada keeps the Kubernetes API as the interface, so existing manifests, Helm charts and tools continue to work. It originated at Huawei Cloud as the successor to Kubernetes Federation, joined the CNCF Sandbox on September 14, 2021, moved to Incubating on December 12, 2023, and graduated on September 3, 2026.
CNCF daily · Sprint 3, post 5 of 21 · Scheduling & Orchestration
At a glance
| Category | Orchestration & Management › Scheduling & Orchestration |
| CNCF status | Graduated. Accepted September 14, 2021; incubating December 12, 2023; graduated September 3, 2026 |
| Written in | Go |
| License | Apache 2.0 |
| Core policies | PropagationPolicy, ClusterPropagationPolicy, OverridePolicy, FederatedResourceQuota |
| Cluster modes | Push (the control plane connects to the member cluster) and Pull (an agent in the member cluster connects out) |
| Scheduling | Cluster affinity, spread constraints, weighted and dynamic replica division, rescheduling and failover |
| Tooling | karmadactl command line, Helm chart and operator installation |
Architecture
flowchart TB
USER[Platform engineer or GitOps tool<br/>kubectl and manifests] ==>|Deployment plus policy| KAPI[karmada-apiserver<br/>Kubernetes compatible API]
KAPI ==>|stores objects| ETCD[etcd]
KAPI ==>|watch| CM[karmada-controller-manager<br/>detect bind create work]
CM ==>|ResourceBinding| SCH[karmada-scheduler<br/>choose clusters and replicas]
SCH ==>|placement decision| CM
CM ==>|Work objects| EXE[Execution controller<br/>push mode]
EXE ==>|apply resources| M1[Member cluster A<br/>cloud]
EXE ==>|apply resources| M2[Member cluster B<br/>edge]
AGT[karmada-agent<br/>pull mode] -.->|pulls Work and applies| M2
M1 -.->|status and health| CM
M2 -.->|status and health| CM
DES[Descheduler and estimator] -.->|capacity hints<br/>rebalance| SCH
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
class KAPI,CM,SCH,EXE,AGT,DES core
class ETCD,M1,M2 data
class USER actor
Key: teal blocks are Karmada components, blue are storage and member clusters, grey is the user. Thick arrows show the main flow from request to placement, dashed arrows show reporting and optional helpers.
| Component | Responsibility |
|---|---|
| karmada-apiserver | A Kubernetes-compatible API server that holds the desired resources and policies, backed by its own etcd. |
| karmada-controller-manager | Matches resources to policies, creates ResourceBinding objects, and renders per-cluster Work objects with overrides applied. |
| karmada-scheduler | Chooses target clusters and divides replicas using affinity, spread constraints, weights and cluster capacity. |
| Execution controller and karmada-agent | Apply Work to member clusters, either by pushing from the control plane or by pulling through an agent. |
| Descheduler and scheduler estimator | Optional components that estimate free capacity per cluster and move replicas that cannot be scheduled. |
Design principle. Keep the Kubernetes API and add policy beside it. Resources stay unmodified, and a separate PropagationPolicy says where they go, so a workload does not have to be rewritten to become multi-cluster.
Production reference design
A common setup runs the Karmada control plane in a small, dedicated cluster and joins cloud and edge clusters as members.
- Install the control plane. Use the Helm chart or the CLI, with its own highly available etcd:
Pin the version, and run several replicas of each component in production.karmadactl init --karmada-data /etc/karmada --crds <crds-tarball> - Join clusters. Use push mode for reachable clusters and pull mode for clusters behind firewalls or at edge sites:
karmadactl join cloud-aws --kubeconfig <karmada-kubeconfig> \ --cluster-kubeconfig <aws-kubeconfig> karmadactl register <karmada-endpoint> --token <token> \ --discovery-token-ca-cert-hash <hash> --cluster-name edge-vizag - Define placement. Divide replicas between clusters by weight:
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: { name: web, namespace: shop } spec: resourceSelectors: - { apiVersion: apps/v1, kind: Deployment, name: web } placement: clusterAffinity: clusterNames: [cloud-aws, edge-vizag] replicaScheduling: replicaSchedulingType: Divided replicaDivisionPreference: Weighted weightPreference: staticWeightList: - { targetCluster: { clusterNames: [cloud-aws] }, weight: 2 } - { targetCluster: { clusterNames: [edge-vizag] }, weight: 1 } - Customise per cluster. An
OverridePolicychanges fields for chosen clusters, such as pointing the edge cluster at a local registry:apiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: { name: web-edge, namespace: shop } spec: resourceSelectors: - { apiVersion: apps/v1, kind: Deployment, name: web } overrideRules: - targetCluster: { clusterNames: [edge-vizag] } overriders: imageOverrider: - { component: Registry, operator: replace, value: registry.edge.local } - Enable failover and observe. Turn on cluster failover so workloads move when a cluster becomes unhealthy, and monitor binding status and propagation lag.
Typical uses include multi-region high availability, cloud and edge placement, cloud bursting, migration between clusters, and uniform policy across a fleet. Check API versions against the Karmada release you install.
Operational considerations
- The control plane is a new critical system. Back up its etcd, run it highly available, and plan upgrades before member clusters.
- Connectivity model. Push mode needs network access from the control plane to each member; pull mode needs only outbound access from the member and suits edge sites.
- Policy conflicts. Several policies can match one resource. Use priorities and explicit selectors, and review the resulting
ResourceBinding. - Stateful workloads. Karmada places resources; it does not replicate data. Databases need their own cross-cluster replication, and traffic between clusters needs a network layer.
- Version skew. Member clusters run different Kubernetes versions. Test resource API compatibility before propagating newer APIs to older clusters.
Adoption
- Huawei Cloud created Karmada and builds its multi-cluster products on it.
- Other cloud and platform vendors, particularly in China and Asia, and enterprises such as telecommunications and internet companies, contribute to and run Karmada; the project publishes an ADOPTERS file in its repository.
- Graduation in 2026 indicates a mature governance and adopter base; teams should check the repository’s current list for organisations relevant to their sector.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Argo CD ApplicationSets | GitOps generates an application per cluster | Git-driven multi-cluster deployment without a federated control plane; see the Argo brief |
| Flux | One Git source reconciled by each cluster | Pull-based fleets with per-cluster configuration; see the Flux brief |
| Open Cluster Management (CNCF Sandbox) | Hub and managed cluster model | Policy-centred fleet management, common in Red Hat environments |
| Rancher Fleet | GitOps at scale | Large fleets managed through Rancher |
| Cloud fleet services (GKE Fleet, Azure Fleet Manager) | Provider-managed multi-cluster | Estates concentrated on one cloud |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Uses native Kubernetes APIs, so existing manifests work | An additional control plane to operate and secure |
| Rich scheduling: weights, spread, capacity-aware, failover | Does not solve data replication or cross-cluster networking |
| Push and pull modes suit cloud and edge | Learning curve for policies, bindings and work objects |
| Graduated CNCF project with a broad contributor base | Some Kubernetes APIs are awkward to propagate |
| Centralised override and quota management | Debugging spans control plane and member clusters |
Recommendation
Adopt for organisations that run many clusters and need workload placement, failover and consistent policy beyond what per-cluster GitOps provides. Start with a control plane and two member clusters, propagate one stateless Deployment with a weighted policy, test failover by cutting a member, and add Services, overrides and quotas gradually. Teams with a handful of clusters may find Argo CD ApplicationSets or Flux simpler.
References: CNCF project page · Karmada website · Karmada repository · CNCF Landscape