Multi-Cluster Kubernetes with Linkerd: Federated Services, GitOps, DR, and Lifecycle Management

TL;DR

• If you run 3 or more Kubernetes clusters for high availability, disaster recovery, migration, or an acquisition, Linkerd secures traffic between services across those clusters.
• Cluster linking connects clusters through gateways. You choose which services to export, and Linkerd creates local names for the remote services.
• Linkerd 2.17 (December 2024) added federated services for cross-cluster routing. Linkerd 2.18 (April 2025) added GitOps-compatible cluster linking, so you can manage links through declared configuration.
• Buoyant Enterprise for Linkerd adds fleet upgrade automation and zone-aware routing. Buoyant Cloud gives you a cross-cluster topology view.

Why cross-cluster Kubernetes traffic needs a service mesh

A Kubernetes Service gives your pods a stable name and routes requests to endpoints inside one cluster. When an application calls a service in another cluster, Kubernetes doesn’t automatically provide a reachable address or keep that address current.

You can connect clusters through load balancers and ingress gateways, but you must maintain the destination addresses and egress rules yourself. A service that moves during a region migration can leave callers using an old address.

Cross-cluster calls also need a shared way to authenticate workloads. A service account in one cluster doesn’t automatically give its pod an identity that another cluster trusts, so you must configure trust and authorization across that boundary.

Native Service routing won’t send requests to a healthy remote cluster when local pods fail. DNS-based failover requires you to change records, and clients may continue using cached addresses. Meanwhile, separate cluster dashboards can leave you tracing one request through disconnected logs and metrics.

HA and DR incidents put pressure on routing and failover. Migrations and M&A integrations make the same gaps persistent as you connect services across different networks and trust policies.

How Linkerd's multi-cluster architecture works

Linkerd starts with a shared trust anchor, a root certificate that lets clusters recognize each other’s workload identities. You install Linkerd with that root certificate and a separate issuer certificate in each cluster, then install the multicluster extension, which adds a gateway for cross-cluster traffic.

Next, you link the clusters with a Link resource. The link records the remote gateway’s address and identity and gives a service-mirror controller access to the remote cluster’s Kubernetes API. You choose which services cross the boundary by adding mirror.linkerd.io/exported=true to each one. The controller then creates a mirrored Service in the consuming cluster and points its traffic at the remote gateway.

Mutual TLS protects the connection between meshed workloads and the gateway. Before forwarding a request, the gateway checks that the caller presents a certificate trusted by the shared root. You can inspect traffic to the gateway with linkerd viz tap and check for tls=true; an unmeshed client without a valid identity can’t use the mirrored service.

Linkerd 2.17, released in December 2024, added federated services. Federation brings service instances in multiple clusters under a single federated service name, so callers can use that name as traffic shifts between available clusters rather than select a mirrored service themselves.

Linkerd 2.18, released in April 2025, added GitOps-compatible cluster linking. You can keep link configuration in Git and apply it through your deployment workflow, alongside the service export labels that decide what each cluster exposes.

Cross-cluster identity and mTLS for audit trails

Linkerd ties each meshed workload’s cryptographic identity to its Kubernetes ServiceAccount. When a request crosses clusters, the receiving gateway checks the caller’s certificate against the shared trust anchor before forwarding it. That gives you a workload identity to use when reviewing which services were permitted to communicate across a regulated data boundary.

You can also verify encryption on a live cross-cluster connection. Linkerd’s multi-cluster guide shows how to inspect gateway traffic with linkerd viz tap and confirm tls=true. A live check documents the connection you observed, so retain the relevant traffic records and authorization policies if an auditor needs historical evidence.

If your audit requires FIPS-validated cryptography, Buoyant Enterprise for Linkerd provides validated modules for the control plane and data plane. Open-source Linkerd’s mTLS alone doesn’t establish FIPS validation.

Automated DR failover without DNS tricks

DNS-based failover depends on clients refreshing a failed cluster’s address. Some clients cache DNS answers beyond the requested TTL, and existing connections can remain open. With Linkerd’s federated services, a federated service keeps one service name while requests can move to a healthy backend in a linked cluster without a DNS record change.

Traffic-layer failover still needs a working destination. The remote gateway must be reachable, the standby cluster needs capacity, and stateful services need usable data. Moving requests won’t restore a service whose database can’t accept writes.

Lunar plans quarterly production-cluster failover drills across its multi-cloud setup. A drill can check whether requests reach the standby and measure how long recovery takes. For stateful services, you should also verify that the standby can serve current data.

Lifecycle management across 10+ clusters with BEL

Upgrading Linkerd by hand across 10 clusters means tracking control plane and proxy versions in every cluster, then checking each upgrade before moving on. A missed cluster can leave you running different mesh versions longer than planned.

Buoyant Enterprise for Linkerd (BEL) adds a lifecycle operator for that work. You declare the desired control plane and data plane versions through ControlPlane and DataPlane custom resources (CRDs), and the operator carries out the upgrades across the fleet. Instead of issuing separate upgrade commands in every cluster, you manage the version change as a single operation. You still choose when to upgrade and check service health afterward, but you don't have to patch each cluster by hand.

Fleet-wide visibility with Buoyant Cloud

Buoyant Cloud puts linked clusters in one topology view, so you can see which services communicate across cluster boundaries. You don't have to piece together separate cluster dashboards to find a cross-cluster call.

Linkerd supplies request volume, success rate, and latency for meshed services and routes without changes to application code. When a service starts failing after traffic shifts to another cluster, you can check those metrics alongside the topology view to narrow down where the errors appear. Your existing observability tools can still handle logs and other application data.

Buoyant Cloud surfaces certificate expiry warnings well in advance. Trust anchor rotation itself is automated by BEL's in-cluster trust-rotation operator, which today targets a single cluster at a time.

HAZL: cost-aware zone-local routing

Cross-zone data transfer charges add up when services send routine requests to pods in other availability zones. Calls between linked clusters can incur those charges too when traffic crosses zone boundaries.

High Availability Zonal Load Balancing (HAZL), available only in Buoyant Enterprise for Linkerd (BEL), favors endpoints in the caller’s zone when local capacity is healthy. If local endpoints degrade, HAZL expands routing to other zones. It tracks per-endpoint load (latency times throughput, roughly the in-flight requests) and widens to other zones when load crosses a set threshold, including for multi-cluster traffic within a region.

Kubernetes’ Topology Aware Routing uses endpoint hints to favor local traffic, but it doesn’t widen routing gradually in response to zone health. HAZL gives you a way to reduce routine cross-zone traffic while retaining access to healthy endpoints elsewhere.

Linkerd vs Istio vs Cilium for multi-cluster

For multi-cluster Kubernetes, compare what each option connects and how much you’ll need to configure. Layer 7 (L7) behavior means routing and balancing individual HTTP or gRPC requests, rather than connecting services across a network.

If you need cross-cluster failover for gRPC services, Linkerd gives you request-level balancing through its workload proxies without adding Istio’s topology choices to the operating plan. Cilium ClusterMesh fits a different starting point when you already use Cilium and mainly need clusters connected at the network layer.

Pick Istio if you depend on Envoy customizations or need its broader traffic controls. Pick Cilium if cross-cluster networking is the job and request-level mesh routing can wait.

Best fit by use case

• Best for HA. Linkerd’s federated services let you route requests across linked clusters when a service needs capacity or a healthy destination elsewhere. You can keep the application’s service name stable while changing where requests land.
• Best for DR. Traffic-layer failover gives you a way to test recovery without waiting for DNS caches to expire. Lunar planned quarterly production-cluster failover drills, a useful model for checking whether your standby cluster can actually take traffic.
  
• Best for cloud or region migration. Linkerd lets services communicate across the old and new clusters while you move workloads in stages. During its AWS expansion, Expel connected GCP data services to AWS workloads through mesh-managed proxies and forwarding services.
• Best for M&A integration. Cluster linking gives you a shared way to identify and reach services across environments you haven’t consolidated. Lunar operates 9 Kubernetes clusters across 3 cloud providers, and its platform was built to accommodate future acquisitions. You’ll still need to decide which acquired services should be reachable.
• Best for regulated data boundaries. Linkerd gives cross-cluster calls cryptographic workload identities, mutual TLS, and authorization policies, so you can control which services communicate. If your audit requires FIPS-validated cryptography, you’ll need Buoyant Enterprise for Linkerd. The open-source build doesn’t provide that validation.

Customer evidence at scale

Xbox Cloud Gaming runs Linkerd across 26+ Kubernetes clusters and roughly 22,000 pods on Azure, figures from Xbox's CNCF blog post ahead of its KubeCon EU 2022 talk. Xbox replaced an in-house mutual TLS system with Linkerd to encrypt traffic across that fleet. The deployment shows Linkerd operating at scale, though the published figures don’t establish how much traffic crosses cluster boundaries.

Expel used Linkerd-managed proxies and forwarding services to connect GCP-based data services to workloads deployed during its AWS expansion. Expel expects HAZL to cut cross-zone transfer costs, but its case study reports expected savings rather than a measured reduction.

Lunar runs 9 Kubernetes clusters across AWS, Azure, and Google Cloud, supporting more than 250 microservices. Linkerd connects the clusters, and Lunar uses Envoy-based gateways in each cluster to expose services across clouds. After acquiring Lendify and PayLike, Lunar built that multi-cloud backbone with future acquisitions in mind.

Getting started with Linkerd multi-cluster

Start with Linkerd’s open-source multicluster extension. Install Linkerd in your first 2 clusters with a shared trust anchor, link the clusters, and export 1 service. Then send a request across the cluster boundary and check that the connection uses mutual TLS.

You can use that small test to check routing and identity before you depend on cross-cluster traffic for failover. If you later need automated mesh upgrades, HAZL for zone-local routing, or FIPS-validated cryptography, Buoyant Enterprise for Linkerd is the upgrade path.

The takeaway for platform teams

For a platform running 3 or more clusters, Linkerd makes cross-cluster traffic a repeatable operation through declarative links and federated services. BEL adds fleet upgrade management when patching each cluster separately becomes burdensome. You still need to rehearse failover and reserve capacity in the surviving clusters, but the mesh no longer requires a custom operating model for every new cluster.

FAQs

How many clusters do you need before Linkerd multi-cluster makes sense?

Linkerd can link 2 clusters. You should consider it when services must communicate across clusters and you need shared identity, traffic controls, or failover. A third cluster doesn’t trigger a technical requirement, but it does add more links to manage.

Does multi-cluster require Buoyant Enterprise for Linkerd?

No. Open-source Linkerd supports cluster linking, mirrored services, and cross-cluster mutual TLS. Buoyant Enterprise for Linkerd adds capabilities such as lifecycle automation and HAZL, which keeps traffic zone-local when healthy.

How does Linkerd failover differ from DNS-based failover?

Linkerd routes requests through the mesh using configured services and traffic rules. You can shift traffic to a remote cluster without waiting for clients to refresh cached DNS records, but you should drill the failover path before relying on it for disaster recovery.

Can Linkerd connect clusters on different cloud providers?

Yes, provided the clusters share a trust anchor and their gateways can reach each other. You’ll also need the API access required to establish the cluster links.