The networking gap in multi-cluster
Solving configuration management (GitOps) is only half the problem. The other half is networking. Once you have services running in multiple clusters, how do they talk to each other?
Inside a single cluster, services communicate using internal DNS: http://checkout.default.svc.cluster.local. This address is only meaningful within that cluster's network. A pod in Cluster A cannot resolve or reach checkout.default.svc.cluster.local in Cluster B — the address simply doesn't exist from Cluster A's perspective.
Your options without a service mesh:
- Public LoadBalancers: Expose each service to the internet. Works, but traffic is unencrypted by default, you pay for egress, and you lose service identity.
- VPN / VPC Peering: Connect the cluster networks at the infrastructure level. Works for same-cloud scenarios but becomes complex across cloud providers and doesn't give you application-level traffic control.
How federated service meshes solve this
A federated service mesh (Istio multi-cluster, Linkerd multi-cluster, or Cilium Cluster Mesh) creates a secure, transparent bridge between clusters at the application layer. Here's how Istio's multi-cluster federation works:
Step 1: Shared Root CA
Both clusters are configured with the same Root Certificate Authority. Every pod's sidecar proxy (Envoy) receives a certificate signed by this shared root. This means pods in Cluster A can cryptographically verify the identity of pods in Cluster B.
Step 2: East-West Gateways
Each cluster exposes a dedicated East-West Gateway — a special Istio ingress gateway that only handles inter-cluster traffic. It gets a public IP (or a private IP if clusters share a network), and every other cluster's gateway address is registered as the entry point for reaching that cluster.
Step 3: Service endpoint export
You annotate the services you want to share across clusters as visible to the mesh (networking.istio.io/exportTo: "*"). Istio's control plane (or a shared Istio control plane) then propagates that service's endpoints to the other cluster's service registry.
Step 4: Transparent cross-cluster calls
When the frontend pod in Cluster A calls http://checkout.ecommerce.svc.cluster.local:8080, the Envoy sidecar intercepts the call. It checks the service registry and finds that checkout has endpoints in both Cluster A (local) and Cluster B (remote). It applies load balancing rules — or failover rules if local endpoints are unhealthy — encrypts the traffic with mTLS, and tunnels it to Cluster B's East-West Gateway, which decrypts and delivers it to the checkout pod.
To the application code, this is indistinguishable from a local call. No code changes required.
Traffic policies across clusters
Once the mesh federation is established, you get the full power of service mesh traffic management across cluster boundaries:
- Failover: Route to Cluster B's checkout only if Cluster A's checkout is unhealthy.
- Locality-aware load balancing: Prefer local endpoints, spill over to remote only when local capacity is exhausted.
- Weighted routing: Send 10% of checkout traffic to Cluster B (for canary testing a new region).
These policies are expressed as an Istio DestinationRule — a resource that defines outlier detection (how many consecutive errors before a pod is ejected from the load-balancing pool), connection pool limits, and locality-aware load balancing that prefers same-region endpoints before failing over to a remote cluster.
A common interview question is: "How do services in different Kubernetes clusters communicate securely without exposing them to the public internet?" Many candidates answer 'VPC peering' — which is infrastructure-level and cloud-specific. The stronger answer describes a federated service mesh: East-West Gateways handle the transport, mTLS with a shared Root CA handles encryption and identity, and the mesh control plane handles service discovery. This works across clouds and gives you application-layer observability (traces, metrics per service pair) that VPC peering cannot provide.