Platform Monkey ctx

Multicluster Kubernetes in 2026: Federation Is Dead, Now What?

· By
Sources

For years, the industry chased the dream of a "single pane of glass" for Kubernetes—a way to treat a dozen clusters across three clouds as one giant pool of resources. This was the promise of Kubefed. It failed because it tried to be a meta-orchestrator that wrapped native resources in complex "Federated" versions, creating a massive abstraction tax that broke every existing Helm chart and GitOps pipeline.

In 2026, the paradigm has shifted. We no longer "federate" clusters; we propagate resources or virtualize nodes. The goal is no longer a single logical cluster, but a coordinated fleet of independent clusters.

The Modern Blueprint: Hub-and-Spoke Propagation

The gold standard for enterprise multi-cluster management is now the Hub-and-Spoke Propagation pattern. Instead of a wrapper, the Hub (e.g., Karmada) acts as a native Kubernetes API server that accepts standard apps/v1 Deployment or v1 Service objects and replicates them to member clusters based on a set of policies.


[ Developer / GitOps ]
       |
       v
[ Hub Control Plane (Karmada) ] <--- [ Propagation Policies ]
       |
       +-----------------------+-----------------------+
       |                       |                       |
       v                       v                       v
[ Member Cluster A ]     [ Member Cluster B ]     [ Member Cluster C ]
 (Prod-US-East)           (Prod-EU-West)           (DR-Region)
       |                       |                       |
       +-----------+-----------+-----------+-----------+
                   |                       |
           [ Network Mesh ] <--- [ Submariner / Cilium ]
           (L3/L4 Tunneling & Cross-Cluster Pod IP Routing)

Technical Mechanics: Resource Propagation

The critical distinction in this architecture is that the member clusters never see "Federated" objects. They receive 1:1 copies of the native YAML. The logic of where and how many replicas go to each cluster is decoupled into a PropagationPolicy.


apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: api-gateway-policy
spec:
  resourceSelector:
    matchLabels:
      app: api-gateway
  placement:
    clusterWeights:
      - clusterNames: [ "us-east-1" ]
        weight: 70
      - clusterNames: [ "eu-west-1" ]
        weight: 30
    replicaScheduling:
      - replicaRange: [ 1, 10 ]
        clusterNames: [ "us-east-1" ]

Solving the Service Discovery Gap

Multi-cluster networking is the primary failure point of most deployments. While tools like Submariner or Cilium ClusterMesh handle the L3 routing (making Pod IPs routable across clusters), you still need a way to resolve foo.svc.cluster.local to a pod in a different cluster.

Modern blueprints use EndpointSlice Synchronization. The Hub monitors the EndpointSlices of a service in all member clusters and mirrors them back to every cluster. This allows a pod in Cluster A to send traffic to a pod in Cluster B using a native Kubernetes Service name.


apiVersion: networking.karmada.io/v1alpha1
kind: MultiClusterService
metadata:
  name: global-api-service
spec:
  serviceSelector:
    matchLabels:
      app: api-gateway
  # Synchronizes EndpointSlices across all selected clusters
  syncPolicy:
    type: AllClusters

Alternative Pattern: Transparent Virtualization

For teams that cannot afford a dedicated Hub control plane, Virtual Node patterns (via Liqo or Admiralty) provide a "transparent" experience. Instead of propagating resources, these tools project the capacity of a remote cluster into the local cluster as a VirtualNode.

When the local scheduler finds no room for a pod, the pod is scheduled onto the Virtual Node. The tool then mutates the pod and executes it on the remote cluster, leaving a "Proxy Pod" (placeholder) on the local cluster to maintain API consistency.

Production Realities

Multi-cluster is not a "free" win; it introduces specific failure modes that differ from single-cluster ops:

Who Should Skip This

You should NOT implement a multi-cluster federation/propagation pattern if: