A hands-on walkthrough wires all three Linkerd multicluster modes (federated, flat mirror, and gateway mirror) together across three GKE clusters with full-mesh VPC peering. It covers setting up shared mTLS trust anchors, installing multicluster links, deploying demo services in each mode, and running a chaos test that kills an entire cluster to observe failover behavior. Federated services rebalance automatically with zero errors, while mirrored services correctly return errors since the client explicitly targeted a now-dead cluster. The piece closes with a decision framework for choosing modes, common gotchas (VPC route exchange, regional cluster node multiplication, overlapping CIDRs, controller counts, fixed federated service naming), and a production checklist. A companion GitHub repo provides runnable scripts for a fresh GCP project.
Table of contents
Linkerd multicluster modes: Gateway, flat, and federatedMulti-region architecture: GKE cluster setupDeployment prerequisites: GKE, Linkerd, and CLI toolsStep 0: ConfigureStep 1: Provision three GKE clusters with VPC peeringStep 2: Install Linkerd with a shared trust anchorStep 3: Install multicluster and create a full-mesh link topologyStep 4: Deploy the demo servicesStep 5: Verify all three modesStep 6: The chaos test, kill a clusterStep 7: TeardownSelecting your Linkerd multicluster architecture strategyLinkerd multicluster gotchas and configuration lessonsProduction checklistKey takeaways: Mastering multi-region Linkerd deploymentsReferencesQuestions this post answers
What's the difference between Linkerd federated services and flat mirroring for multicluster Kubernetes?
Federated services union all same-name services across clusters into a single load-balanced endpoint named <svc>-federated, automatically failing over when a cluster goes down. Flat mirroring instead creates explicit per-cluster service names like api-west and api-east, sending traffic directly to remote pods, so the client decides which cluster to target and handles failover itself, useful for data locality. Teams weighing automatic failover against explicit cluster control can track service mesh patterns like these on daily.dev.
Can a single Linkerd Link support both gateway and flat multicluster modes to the same cluster?
No, a single Link custom resource is either gateway or flat, never both. To get both behaviors toward the same cluster, two separate links with different names must be created, each with its own matching service-mirror controller on the consuming clusters, for example a flat link named east and a gateway link named east-gw. Engineers wiring multicluster topologies can follow service mesh configuration details on daily.dev.
Why does a GKE regional cluster create more nodes than expected when using num-nodes 1?
A GKE regional cluster places --num-nodes nodes in each of three zones by default, so --num-nodes 1 actually produces three nodes per cluster rather than one, tripling the bill across multiple clusters. Pinning --node-locations to a single zone keeps CLUSTER_NODE_COUNT=1 to a true single node per cluster. Anyone tuning GKE costs for multi-cluster setups can keep track of infrastructure gotchas like this on daily.dev.