Multicluster Operations and Failover for Kubernetes
Achieve true multi-cluster resilience with zero-config service mirroring and automated, cross-cluster failover.
Why one cluster is a single failure domain
Relying on a single Kubernetes cluster is a huge operational risk. Even with internal redundancies, a single configuration error, cloud outage, or software glitch can paralyze the entire cluster and take your services offline. By deploying across multiple clusters, you create independent firewalls that contain failures, ensuring a single regional or technical issue won't trigger a total business outage.
Linkerd connects Kubernetes services across cluster boundaries securely, without application changes, and independent of network topology. Every cross-cluster connection is encrypted and authenticated with mTLS, whether across a VPC or the public internet. Read the docs ↗
What you get with Buoyant Enterprise Linkerd
Federated services and cross-cluster traffic management, built into your service mesh with no extra tooling required.
Survive a cluster failure
Federated services distribute traffic across replicas in every member cluster, so clients tolerate the loss of any one.
Identity across the boundary
Pod-to-pod networking mode preserves workload identity cross-cluster, so cross-cluster authorization policy works the same as in-cluster.
Migrate without downtime
Incrementally migrate services between clusters without requiring code changes or interrupting developer workflows.
Sub-10ms gateway hops
Eliminate costly gateway hops
Tradeshift achieved direct pod-to-pod cross-cluster routing without sacrificing security or latency.
How it works
Linkerd mirrors services across your clusters and secures all cross-cluster traffic with mTLS. In pod-to-pod mode, workload identities stay intact even when crossing cluster boundaries. By combining same-named services into a single federated service, Linkerd automatically distributes traffic across clusters so your app stays available even if an entire cluster goes down. A shared root of trust anchors identity and security across every environment.
Zone-aware load balancing with HAZL
Under normal load HAZL keeps requests in-zone; when the in-zone endpoint is overloaded or returning errors, it spills to another zone, then returns in-zone as load recovers.
Two Modes of Multicluster
Linkerd can handle multicluster in two different ways: gateway-based multicluster can safely use any transport between clusters (even the public Internet), while pod-to-pod multicluster provides smoother failover and better identity preservation. Whichever you choose, most teams can get their first two clusters meshed in an afternoon with no application changes.
Gateway-based multicluster
✗ No federated services
✗ No active-active distribution
✗ No circuit breaking across clusters
✓ mTLS cross-cluster connections
✓ No tuning, no code changes
Pod-to-pod multicluster
✓ Federated services (active-active)
✓ Request-level load balancing across clusters
✓ Circuit breaking for degraded clusters
✓ mTLS + workload identity across clusters
✓ No tuning, no code changes
Why Buoyant Enterprise for Linkerd for multi-cluster operations
1
Federated services for high availability
A federated service is a union of services that share the same name and namespace in multiple clusters. Traffic is distributed across all replicas, so clients are resilient even if one cluster fails entirely: a degraded cluster's endpoints simply drop out of the pool that is managed by the same request-level load balancing and circuit breaking Linkerd already uses for any unhealthy endpoint.
2
Federation moves traffic while your data layer stays separate
Federation distributes requests at L7 but does nothing to manage state. That means you can federate the stateless tier freely, but for anything with a write path, replication and consistency remain your datastore’s responsibility.
3
Application-layer identity across clusters
In pod-to-pod mode, Linkerd preserves workload identity across the boundary, letting you write cross-cluster authorization policy as easily as policy for a single cluster. By contrast, Gateway mode is simpler but loses client identity at the hop between clusters.
4
Cloud migration without downtime
Shift traffic service by service between clouds with mTLS with no downtime. Enable fast rollback by simply reversing traffic weights. Linkerd (BEL) extends external-workload meshing to Windows VMs, the first service mesh to officially support Windows applications running outside Kubernetes.
Trusted for multicluster operations in production
Every claim is backed by a reproducible demo, a published cost model, and a CNCF track record.
Trusted in production
Trusted in production by Tradeshift, Expel and teams at Walmart, HP, and Expedia.
Migration without downtime
Tradeshift migrated to Amazon EKS without downtime. Expel expanded to AWS with Buoyant.
Frequently asked questions
What's the difference between gateway and flat mode?
Gateway routes through a gateway (simpler, adds a hop, loses identity); flat connects pods directly (keeps identity, avoids the hop, needs direct pod-to-pod IP connectivity between clusters.
How does cross-cluster failover work?
Federated services distribute traffic across replicas in every member cluster; a degraded cluster's endpoints drop out via load balancing and circuit breaking. It moves traffic at L7 and does nothing for state.