Linkerd federation keeps the app running when a whole Kubernetes cluster dies

CNCF Ambassador and Linkerd contributor Dominik Táskai walks through Linkerd's multicluster extension across three GKE clusters in three regions, tears one down, and watches the remaining pods absorb the traffic without a single application change. The post, published on the CNCF Blog on 27 July 2026, is a working reference for teams considering cluster federation as their zero-downtime primitive on Kubernetes.

The three multicluster modes, in one page

Linkerd multicluster ships three modes for moving traffic between clusters.

• Hierarchical mode routes cross-cluster traffic through a gateway. Only the gateway IP has to be reachable, so it runs on any network you can wire together.
• Flat mode gives pods in different clusters direct pod-to-pod IPs. That requires a flat network where pod IPs actually route.
• Federated mode also needs pod-to-pod connectivity, with a twist: services that carry the label mirror.linkerd.io/federated=member are unioned across clusters into a single logical service with the suffix -federated. So frontend in three clusters becomes frontend-federated, backed by every healthy replica.

The gateway mode is the compatibility play. Federation is the availability play. Táskai is explicit that each multicluster link runs in a single mode; you do not mix modes on the same link.

What the walk-through actually proves

The demo is deliberately small. Three GKE clusters in three regions, three replicas of a frontend service in each, nine pods total, and a full-mesh link topology of six directional links so every pair of clusters can call every other pair in both directions.

Before the failure, traffic splits evenly at 33 percent per cluster. Táskai tears one cluster down. Traffic rebalances to 50/50 across the six surviving pods, with zero errors during the transition. No application change. No config change.

That is exactly the failover story teams want on a slide. The catch is that "no application change" is doing a lot of work in that sentence.

What it costs you to wire up

The rebalancing is free at the application layer because everything expensive happens below it. The post is explicit about the price of admission.

• VPC peering has to be configured symmetrically. Táskai flags --export-custom-routes and --import-custom-routes on both sides as easy to forget.
• Regional GKE clusters multiply your node count by three unless you pin --node-locations to a single zone. That is a real bill.
• Overlapping pod CIDRs will break peering silently. If two clusters share a range, traffic quietly goes nowhere.
• Each link runs its own service-mirror controller. In the three-cluster full mesh, that is six controllers to keep an eye on.
• Federated service naming is fixed. Your service becomes <svc>-federated, not something you get to pick.

None of this is a blocker. All of it is work a platform team has to plan for before the demo lands in production.

What Linkerd's load balancing will not do for you

The failover story rides on Linkerd load-balancing across healthy endpoints. The post does not claim latency-aware routing, weighted splits between regions, or geographic pinning of a request to its nearest cluster. If your users in Europe should preferentially hit their nearest cluster, federation does not do that for you. You get liveness and even distribution; routing policy on top of that is your problem.

Federation makes the loss of a whole cluster survivable without changing your app. It does not make your network cheaper, your CIDR planning less careful, or your service naming more flexible. Táskai's post is a good reference precisely because it shows both sides. If federation is your zero-downtime strategy, the pod count is the easy part.