Karmada Just Graduated: What Multi-Cluster Kubernetes Maturity Means for Your Single-Region Fleet

On September 8, 2026, at the first-ever joint KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference in Shanghai, the CNCF announced that Karmada — the "Kubernetes Armada" for running applications across multiple clusters, clouds, and regions — had graduated. The TOC vote had landed five days earlier, on September 3.

Here is the bottom line for a team running a Hetzner-only, Cluster-API-managed fleet: graduation doesn't mean you should install Karmada this week. It means the multi-cluster patterns Karmada standardized — propagation policies, declared failover, per-cluster overrides — are now certified production-grade, and you should design your single-region fleet so those patterns slot in later without a rewrite. Borrow the ideas now; adopt the machinery when you have a second failure domain worth scheduling across.

This post backs that verdict with the graduation receipts, what v1.19 actually shipped, how Karmada relates to the Cluster API you already run, and a concrete first experiment for the day you need it.

Graduated, with receipts​

CNCF graduation is not a popularity contest. It certifies a specific checklist: a completed third-party security audit, a formal steering committee with transparent governance, adoption of the CNCF Code of Conduct, and (in Karmada's case) a maintained CII Best Practices Badge. Karmada cleared all of it after a five-year run: first commit in November 2020, Sandbox in September 2021, Incubating in December 2023, Graduated in September 2026.

The scale numbers behind the vote are substantial: more than 1,214 contributors across 292 contributing organizations and over 5,600 GitHub stars. The production adopter list spans Bloomberg and Wellhub globally plus a deep bench of Chinese cloud, telecom, and AI platforms — Alibaba Cloud, Huawei, JDCloud, iFLYTEK, Kuaishou, SenseTime, Trip.com, Vivo, Bilibili, and others. These are not logo-slide adopters: Bloomberg's streaming platform team runs disaster recovery and fleet-wide cluster management on Karmada (and employs a Karmada maintainer), while Trip.com credits it with cross-cluster elasticity, failover, and large-scale workload migration with minimal application disruption.

For a self-hosted PaaS team, that adopter shape matters more than the badge. Graduation plus a Bloomberg-grade production footprint means Karmada's APIs — PropagationPolicy, OverridePolicy, ResourceBinding — are now a stable contract you can build against, not a moving target that might strand your manifests.

What Karmada is, in 60 seconds​

Karmada is a hub-and-spoke control plane: you submit ordinary Kubernetes manifests (Deployments, Services, ConfigMaps, CRDs) to the Karmada API server, and it propagates them to member clusters according to policy. The applications themselves don't change — no SDK, no sidecar, no rewritten YAML. Three API concepts do the work:

• PropagationPolicy / ClusterPropagationPolicy — selects resources and declares placement: which clusters, how many replicas where, and what happens on failure.
• OverridePolicy — applies per-cluster differences (image tag, resource requests, env vars) on top of the shared template.
• ResourceBinding — the scheduler's record of where each resource actually landed.

If you run Cluster API, the natural question is how the two relate. They are complementary, not competing: Cluster API provisions and lifecycle-manages clusters; Karmada schedules and fails over workloads across them. CAPI answers "which machines exist and what Kubernetes version do they run"; Karmada answers "which cluster should this Deployment's replicas live on, and where do they go when a cluster dies." One manages the fleet's machines, the other manages the fleet's workloads. A CAPH-provisioned Hetzner fleet with Karmada on top is a coherent stack, not a contradiction — CAPI hands Karmada new member clusters, Karmada hands tenants one logical deployment target.

v1.19: the release that came with the diploma​

Graduation arrived alongside Karmada v1.19 (released August 31, 2026), and the release notes show where the project's center of gravity is moving: AI training and resource-aware scheduling. Four items matter:

Multi-component workload scheduling, Phase IV. Modern AI and big-data workloads — Flink deployments, distributed training jobs — are composed of multiple pod templates with different resource needs. v1.19 adds per-component scheduling results (spec.clusters[*].components) to ResourceBinding and ClusterResourceBinding, with the scheduler persisting per-component replica assignments behind the MultiplePodTemplatesScheduling feature gate. This is foundation work for scaling and rescheduling multi-template workloads, tracked upstream as issue #7492.

Priority-based scheduling goes Beta, enabled by default. Workloads declared with spec.schedulePriority in their propagation policy are now scheduled in priority order, so critical workloads win when everything competes for scheduling throughput. The priority queue got smarter too: bindings whose backoff or unschedulable timeout has elapsed re-enter the active queue in priority order. You can still opt out with --feature-gates=PriorityBasedScheduling=false on karmada-scheduler.

Automatic credential rotation for push-mode clusters. In push mode, Karmada holds long-lived watches against member clusters — and a rotated bearer token used to silently break them until someone restarted components. v1.19 adds a token-refreshing transport layer so rotated credentials are picked up automatically. If you run security-hardened clusters with routine token rotation, this removes a real operational footgun.

Serious performance work. Stripping managedFields from dynamic informer caches cut karmada-controller-manager peak memory from 5 GB to 3.4 GB in a test distributing 20,000 Deployments to two member clusters. The execution controller now owns all member-cluster object modifications while the work-status controller handles status collection only, killing duplicated reconciliation and a class of lost-status bugs.

The honest read: v1.19's headline features serve fleets bigger than yours — multi-cluster AI training, 20,000-Deployment propagation. But priority scheduling default-on and automatic credential rotation are the kind of hardening that makes a future adoption boring, which is exactly what you want from infrastructure.

The Hetzner-only question: borrow now, adopt later​

So what should a single-region, Hetzner-only CAPI fleet actually do? Split the answer:

Three triggers should reopen the decision: a second region or failure domain (the moment placement stops being trivial), GPU pools that must be shared across clusters (watch the multi-cluster DRA roadmap item below), or a DR requirement with teeth (declared failover beats runbook failover when the auditor asks for proof).

Note what this table is really saying: Karmada's value to you today is as a design vocabulary, not a dependency. The teams that will adopt it painlessly are the ones whose deploy pipeline already thinks in templates, placement intents, and overlays.

A concrete first experiment​

When a trigger fires, the smallest meaningful Karmada experiment on a CAPI fleet looks like this: join two CAPI-provisioned clusters (say, fsn1-prod and nbg1-dr) as members, then declare that tenant workloads prefer the first and fail over to the second:

apiVersion: policy.karmada.io/v1alpha1
kind: ClusterPropagationPolicy
metadata:
  name: tenant-default-failover
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      labelSelector:
        matchLabels:
          tenant-serving: "true"
  placement:
    clusterAffinity:
      clusterNames:
        - fsn1-prod
        - nbg1-dr
    spreadConstraints:
      - spreadByField: cluster
        maxGroups: 2
        minGroups: 1
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 60

This single policy captures the whole pitch: ordinary Deployments, selected by label, placed with a declared preference order, with application failover kicking in 60 seconds after the primary stops answering — no per-cluster manifests, no deploy-pipeline changes per region. Validate it by killing the primary cluster's API access in staging and watching replicas reappear in nbg1-dr. If that drill passes twice in a row, Karmada has earned its place in your architecture; if the failure modes surprise you, you've learned it in staging instead of during a real outage.

What to watch next​

Karmada's 2026 roadmap points at the resource-aware control plane: priority-based preemption (not just ordering), multi-cluster queuing for AI training and batch jobs, and multi-cluster support for Kubernetes Dynamic Resource Allocation across GPUs and other accelerators. That last item is the one to track most closely — DRA went GA in Kubernetes 1.36, NVIDIA donated its DRA GPU driver to the CNCF, and the moment multi-cluster DRA lands, a Hetzner fleet with GPU nodes in two regions gets real bin-packing across failure domains instead of one GPU pool per region.

Graduation certifies that Karmada is safe to plan around. For a Hetzner-only fleet, planning around it — templates, placement intents, overlays, declared failover — is the move. The install can wait for the second region; the architecture shouldn't.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.