Multi-Cluster Kubernetes

Most organizations run multiple Kubernetes clusters: dev / staging / prod, multi-region, multi-cloud, or per-tenant. The tooling for managing them as a fleet has matured.

Cluster lifecycle / fleet management

• ★ Cluster API (CAPI) (CNCF) — Kubernetes managing Kubernetes clusters via CRDs. Provider-specific: CAPA (AWS), CAPG (GCP), CAPV (vSphere), CAPZ (Azure), CAPH (Hetzner), CAPL (Linode), etc. The default in 2026.
• Rancher (SUSE) — multi-cluster UI / management plane; commercial backing.
• Open Cluster Management (OCM) — Red Hat-driven; CNCF; multi-cluster apps and policies.
• Crossplane — provision clusters as part of broader infra-as-CRDs.

Workload distribution across clusters

• ★ Karmada (CNCF) — schedule workloads across clusters from a single control plane.
• KubeStellar — newer; multi-cluster + multi-tenant.
• Liqo — peer-to-peer cluster federation.
• Argo CD ApplicationSets with cluster generators — simpler "deploy this app to these clusters" pattern.

Cross-cluster networking

• ★ Submariner — direct pod-to-pod networking across clusters.
• ★ Cilium ClusterMesh — eBPF-native; service discovery + connectivity across Cilium clusters.
• Istio Multi-cluster — federation built into Istio.
• Linkerd Multi-cluster — federation built into Linkerd.
• Skupper — application-layer connections without flat networking.

Cross-cluster service discovery

• Submariner Lighthouse — service.cluster.global DNS.
• Cilium ClusterMesh — same idea, eBPF-based.
• Multi-cluster Services API — emerging Kubernetes standard.

Disaster recovery / failover

• Velero — backup / restore across clusters; see Backup.
• DNS-based failover with health checks (Cloudflare LB, Route 53 health checks).
• Active-active multi-region with stateful replication is hard — design carefully.

When multi-cluster is right

• Geographic distribution — region-local clusters for data sovereignty / latency.
• Multi-cloud for vendor leverage or regulatory reasons.
• Per-tenant isolation — sometimes a separate cluster is the cleanest tenancy boundary.
• Strict failure isolation — one cluster goes down, others keep running.
• Compliance — separate clusters for regulated workloads.

When it's overkill

• Two engineers and one product. A single cluster with namespaces is plenty.
• "What if we need it later?" — wait until you do; multi-cluster has real ops cost.
• You're doing this just to add HA — node-level HA in one cluster covers most failure modes.

Patterns to adopt

• ★ Manage clusters declaratively. Cluster API + GitOps means a cluster definition is a YAML file.
• Separate the management cluster from workload clusters. Don't run everything from one cluster.
• Federate identity, not infra. SSO across clusters; let workloads stay cluster-local.
• Test cluster recreation. Recreate prod from manifests in a sandbox once a quarter.

Pick this if…

• Default declarative cluster lifecycle: Cluster API.
• Workload distribution: Karmada or Argo CD ApplicationSets (simpler).
• Cross-cluster networking: Cilium ClusterMesh or Submariner.
• Multi-cluster UI: Rancher.
• You're not sure you need multi-cluster: stay with one.