Multi-cluster Kubernetes: Karmada graduates from the CNCF

Karmada, a project for running workloads across many Kubernetes clusters, has graduated from the Cloud Native Computing Foundation — the level reserved for projects considered stable and widely adopted in production. Graduation is a useful signal that multi-cluster Kubernetes tooling has matured. It is not a signal that your organisation needs more than one cluster, and the two are easy to confuse.

What was announced

InfoQ reports that Karmada's graduation was announced at KubeCon + CloudNativeCon China 2026 in Shanghai, alongside its v1.19 release. The project counts more than 1,214 contributors from 292 organisations and over 5,600 GitHub stars.

Named production users include Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo, WPS and ZTO. The CNCF sponsor's framing is the right summary of the problem: as organisations scale beyond a single Kubernetes cluster, they need consistent management without added complexity.

What Karmada actually does

Karmada orchestrates workloads across multiple clusters using standard Kubernetes APIs. That is its central design choice: teams keep writing ordinary Kubernetes manifests, and Karmada decides where they run.

Two policy types do the work. A PropagationPolicy says where a workload should be placed and how it should be spread — for example, across clusters in two regions. An OverridePolicy applies cluster-specific differences, such as a different image registry or replica count in one location, without forking the manifest.

The main alternative discussed is Open Cluster Management, which uses a hub-and-spoke agent architecture oriented towards governance and policy distribution. Karmada leans towards workload placement and dynamic scheduling, with caching for cross-cluster queries and multi-cluster service discovery. They answer different questions: "are all our clusters configured correctly?" versus "where should this workload run?"

Why teams end up running multi-cluster Kubernetes

Multi-cluster estates usually arrive for one of a few reasons.

• Regions. Serving users in several geographies, or meeting data residency requirements, often means clusters in several locations.
• Blast radius. A single cluster is a single failure domain for its control plane and for any cluster-wide misconfiguration.
• Isolation. Some organisations separate production from non-production, or one business unit from another, at the cluster level.
• Accident. Each team or project created its own cluster, and nobody ever consolidated them.

The first two are genuine reasons. The third is sometimes justified and often achievable within a single well-run cluster using namespaces, network policies, resource quotas and dedicated node pools. The fourth is the most common, and a federation tool makes it more manageable without making it any less wasteful.

When a second cluster is the wrong answer

Every additional cluster brings its own control plane to upgrade, its own add-ons to keep consistent, its own monitoring, its own certificates and its own upgrade calendar. A tool like Karmada reduces the cost of placing workloads across them. It does not remove the cost of operating them.

That is the same lesson Form3's engineers were blunt about when discussing running on three clouds at once: distribution buys resilience and costs operational capacity, and it only pays off if you already run one environment well. A team that struggles to keep one cluster upgraded will struggle more with five, federation layer or not.

Before adding a cluster, it is worth asking whether the goal could be met inside the existing one. Noisy-neighbour problems are often solved with requests, limits and dedicated node pools. Tenant separation is often adequate with namespaces and strict network policies. Upgrade risk is often better handled by a disciplined upgrade process than by splitting the estate — for example, taking advantage of scheduling improvements such as workload-aware scheduling in 1.37.

What graduation does and does not tell you

CNCF graduation reflects project health: sustained contribution from many organisations, documented governance, security practices and a track record of production use. It is a reasonable proxy for "this project will still be maintained in three years", which matters a great deal for infrastructure you would build a platform around.

It does not tell you whether the project fits your architecture, how hard it is to operate, or whether its model of placement matches how your workloads behave. The adopter list is dominated by very large platforms, several running thousands of services. Their reasons for federating clusters are not necessarily yours, and the operational investment they can absorb is not typical of a mid-sized engineering team.

That is not a criticism of Karmada. It is the normal gap between a technology being ready and a particular organisation being ready for it, and the useful question is always the second one.

When Karmada is worth evaluating

If you genuinely operate several clusters — across regions, clouds or regulatory boundaries — and teams are maintaining near-duplicate manifests per cluster, Karmada's model is attractive. Keeping standard Kubernetes APIs means existing tooling and knowledge carry over, and a CNCF-graduated project carries less adoption risk than it did a year ago.

A sensible evaluation is narrow: pick one stateless workload that already runs in two clusters, express its placement with a propagation policy and its differences with an override policy, and compare that with how you manage it today. Stateful workloads and cross-cluster service discovery are where the hard problems live, so test those deliberately before committing.

The graduation is good news for anyone already running a multi-cluster estate. For everyone else, the more valuable exercise is confirming whether that estate should exist — the kind of question we start with in any Kubernetes implementation review, before tooling enters the conversation.