Multi-cluster concepts — when one cluster is not enough

A single Kubernetes cluster has limits. Multi-cluster deployments address those limits at the cost of operational complexity. This lesson walks the reasons to go multi-cluster, the topology patterns, the trade-offs, and the operational discipline of defining why multi-cluster before choosing the topology.

When one cluster is not enough

flowchart TD
    A[One cluster] --> B[Size limits]
    A --> C[Blast radius]
    A --> D[Environment isolation]
    A --> E[Geography]
    A --> F[Compliance]
    A --> G[Scale]

The reasons:

• Size limits. A single control plane handles ~5,000 nodes and ~150,000 Pods. Beyond that, the API server and etcd saturate. Multi-cluster scales horizontally.
• Blast radius. A control-plane failure takes down every workload. Multi-cluster partitions the blast radius — a regional outage affects one cluster, not all.
• Environment isolation. Production workloads should not share a control plane with dev workloads. A misbehaving dev Pod cannot starve production.
• Geography. Latency to a single region may be unacceptable for global users. Multi-region multi-cluster places workloads closer to users.
• Compliance. Some regulations require data residency (data in the EU stays in the EU). Multi-cluster with regional boundaries satisfies this.
• Scale. A single cluster’s nodes are limited by the cloud’s account quotas. Multi-cluster scales beyond a single account.

The topology patterns

flowchart LR
    A[Multi-cluster topology] --> B[Hub-and-spoke]
    A --> C[Fleet]
    A --> D[Primary-secondary]
    A --> E[Active-active]

The four primary patterns:

• Hub-and-spoke. A central management cluster (the hub) manages multiple workload clusters (the spokes). Tools: Cluster API, Argo CD, Rancher, Tanzu.
• Fleet. A peer-to-peer model where every cluster is equal. No central management. Tools: Cluster API fleet, KubeFed (deprecated), Submariner for service connectivity.
• Primary-secondary. One cluster is active (the primary); the others are passive standbys. Failover is manual or semi-automated. Common for DR.
• Active-active. Multiple clusters serve traffic simultaneously. Requires global load balancing and state replication. Most complex, lowest RTO.

The trade-offs

flowchart LR
    A[Multi-cluster] --> B[Operational complexity]
    A --> C[Cost]
    A --> D[Service discovery across clusters]
    A --> E[Network connectivity]
    B --> F["More clusters to upgrade, monitor, secure"]
    C --> G["Duplicate control plane, networking"]
    D --> H["Submariner, Skupper, or federation"]
    E --> I["VPC peering, VPN, or service mesh"]

The trade-offs:

• Operational complexity. Each cluster is its own upgrade, monitoring, security, RBAC, networking. More clusters = more work.
• Cost. Each cluster has a control plane (3 nodes minimum for HA). Multi-cluster multiplies the control-plane cost.
• Service discovery across clusters. Services in cluster A are not visible in cluster B by default. Tools like Submariner, Skupper, or a service mesh provide cross-cluster discovery.
• Network connectivity. Pods in cluster A cannot reach pods in cluster B without explicit network configuration (VPC peering, VPN, or a service mesh).

The decision framework

The driver determines the topology. A DR driver is served by primary-secondary; an isolation driver by hub-and-spoke; a geography driver by active-active.

The operational failure modes

Multi-cluster fails for predictable reasons:

• Topology chosen without a driver. A fleet topology deployed for DR adds operational complexity without solving the DR requirement.
• Cost not modelled. The control-plane cost of each cluster is underestimated. A 10-cluster deployment triples the infrastructure bill.
• Service discovery not addressed. Services in cluster A are not visible in cluster B; workloads fail to connect.
• Network not designed. Pod-to-pod across clusters requires VPC peering or VPN. Without it, the clusters are islands.
• Upgrade not synchronised. Two clusters on different Kubernetes versions produce subtle compatibility issues.

Quiz

Production discipline

Multi-cluster design in production rests on five non-negotiable elements:

• Define the driver before the topology. DR, isolation, geography, scale, compliance — each points to a specific topology.
• Model the cost. Each cluster has a control-plane cost. Multi-cluster multiplies the bill.
• Address service discovery. Submariner, Skupper, or a service mesh for cross-cluster service connectivity.
• Design the network. VPC peering, VPN, or transit gateway for cluster-to-cluster traffic.
• Synchronise upgrades. A fleet with mismatched Kubernetes versions produces subtle compatibility issues.

Multi-cluster is a tool, not a goal. The discipline is to use it only when the driver justifies the complexity.