A spare Kubernetes cluster is not the same thing as failover. It can be healthy, paid for, and running the same workload in another region, but still be useless during an outage if traffic, identity, and service discovery do not treat it as part of the same operational surface.

CNCF's July 27 post on federating clusters for zero-downtime Kubernetes is useful because it moves past the comforting diagram. Dominik Taskai walks through a Linkerd multicluster setup across three GKE clusters, with a full-mesh link topology, a shared trust anchor, three service exposure modes, and a failure test that knocks out an entire cluster. The important part is not that there are three clusters. It is that the service plane knows what each cluster is supposed to mean.

clusters:
  west  - us-central1
  east  - us-east1
  north - europe-west1

shared layer:
  common trust anchor
  per-cluster issuers
  six directional links
  service labels choose behavior
The failure story starts before the outage. It starts with how services are named, trusted, and linked.

The Mode Is The Contract

Linkerd's multicluster extension supports several ways to expose a service across clusters, and the CNCF walkthrough makes the distinction concrete. Hierarchical gateway mode exports a service through a reachable gateway. Flat mode mirrors a remote service so traffic can go directly to remote pods. Federated mode unions same-name services into a single federated endpoint and balances across the available clusters.

That difference is not cosmetic. A gateway import is useful when only the gateway IP is reachable. Flat and federated modes require pod-to-pod connectivity, which the demo gets from VPC-native GKE clusters on peered VPCs. The service label becomes a contract: do you want a specific remote service, or do you want one logical service spread across healthy locations?

gateway mirror:
  mirror.linkerd.io/exported=true
  ask for analytics-east-gw
  gateway endpoint is the dependency

flat mirror:
  mirror.linkerd.io/exported=remote-discovery
  ask for api-east or api-west
  remote pod IPs are the dependency

federated:
  mirror.linkerd.io/federated=member
  ask for frontend-federated
  healthy same-name services share load
One mesh can carry all three patterns. The label decides the failure semantics.

Trust Is Part Of Routing

The demo installs Linkerd into all three clusters with a shared root certificate and per-cluster issuer certificates. That detail should not be treated as background setup. Cross-cluster mTLS is part of the service plane. If proxies in one cluster cannot verify the identity of proxies in another, the routing story is incomplete.

The per-cluster issuer pattern is also operationally sane. If one cluster's issuer has to be rotated, it can be rotated without replacing the shared root everywhere. That is the kind of boundary that matters in real production incidents. Regional independence is not just about replicas. It is about how much you can change or recover in one location without shaking the whole platform.

Multi-region reliability is not only placement. It is placement plus trust plus a service name that survives losing a region.

The Failure Test Is The Point

The CNCF post's failure test is the section that makes the architecture feel real. The script scales every deployment in the east cluster to zero replicas, then samples traffic from north against the three service patterns.

The federated frontend behaves the way a platform team hopes it will. Before the failure, traffic is split across west, east, and north. After east disappears, traffic redistributes across west and north with no configuration change and no error spike. As east's pods leave the endpoint list, Linkerd's load balancer simply has fewer healthy destinations.

The mirrored services fail differently, and that is correct. A client that asks for api-east gets failures when east is gone because it explicitly requested the east service. A client that asks for the gateway-backed analytics service also fails when the east gateway is gone. Those are not design failures. They are different contracts. Mirroring gives the client control over where it is going. Federation gives the platform automatic failover for a same-name service.

The Useful Lesson

The lesson is not that every service should be federated. That would be too blunt. Some dependencies should name a specific location because state, compliance, locality, cost, or latency makes location part of the interface. Other services should be location-agnostic because the whole point is to keep serving when one region drops out.

The CNCF walkthrough matters because it shows those modes living together on the same links. A real platform rarely gets to pick one pure pattern. It needs a vocabulary for choosing per service, and it needs diagnostics that make those choices visible when something breaks.

  • Federate stateless front doors when any healthy region can serve the request.
  • Mirror explicit remotes when the client really needs a named regional dependency.
  • Use gateways deliberately where flat pod routing is unavailable or undesirable.
  • Keep trust separable with a shared anchor and independently rotatable issuers.
  • Test failure behavior by removing a cluster from service, not by admiring the diagram.

The Takeaway

Kubernetes makes it relatively easy to create another cluster. It does not automatically create a reliable service plane between clusters. The hard part is deciding which services should collapse into one endpoint, which should remain location-specific, and which trust and network assumptions each mode requires.

That is why this Linkerd demo is worth reading as more than a tutorial. It puts failure semantics into labels, trust roots, links, and endpoint lists. When east goes away, the platform should already know whether the right answer is rebalance, return an explicit remote failure, or route through a gateway. Zero downtime is not a region count. It is a contract that still holds when one region stops answering.

Sources