Karmada graduates from the CNCF five years after entering the Sandbox

Apply a Deployment to a Karmada API server and nothing reaches a member cluster until four controllers have taken a turn. A Policy Controller matches the object against a PropagationPolicy and writes a ResourceBinding ^[12]. The Binding Controller expands that binding into one Work object per target cluster ^[13]. From there an Execution Controller pushes the resulting manifests to each member cluster's own API server ^[14]. Registration and member lifecycle sit with a separate Cluster Controller ^[15].

Placement rules live in two custom APIs. A PropagationPolicy maps one policy to many workloads and carries the constraints: cluster affinity, multi-cluster splitting and rebalancing, and high availability across region, availability zone, cluster or provider ^[10]. An OverridePolicy rewrites the per-cluster differences, such as swapping a container image prefix by region or a StorageClass by cloud provider, without editing the resource template ^[11]. Installation is a Helm chart, and the control-plane components export Prometheus metrics ^[16].

Priority-based scheduling reaching Beta and enabled by default is the line in the v1.19 notes that changes behaviour on upgrade day ^[5]. The scheduler starts ordering work by priority for operators who never touched the setting. The InfoQ account does not say how that ordering treats workloads already placed on member clusters.

The reason an orchestration release is talking about AI at all is capacity. GPU capacity is spread across regions and cloud providers, no single cluster holds enough accelerators, and so workloads have to be split, scheduled and shifted across many systems, per InfoQ ^[7]. What v1.19 adds is better multi-component scheduling for AI training jobs ^[4]. For that to help a particular training run, the components have to tolerate landing in different clusters. Karmada decides where the pieces go; whether they can run apart is a question about the network and storage between those clusters, and the described propagation path ends at the member API server ^[14].

Trip.com runs it 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," said Honghui Yue, Senior Development Expert at Trip.com ^[22]. Chad Beaudin, the project's TOC sponsor, said teams scaling past one cluster "need consistent management without added complexity" ^[21].

Karmada entered the CNCF Sandbox in September 2021 and moved to Incubating in December 2023 ^[17]. That is 27 months to the middle tier and another 33 to graduation, 60 months in the foundation ^[1]. The project now counts more than 1,214 contributors from 292 organizations and more than 5,600 GitHub stars ^[18].