GCP ACE: Multi-Cluster Networking with Cloud Service Mesh — Single vs. Multiple Network
Earlier in this module, Fleet Networking covered multi-cluster Services and the multi-cluster Gateway — both Kubernetes-API-level mechanisms. Cloud Service Mesh has its own answer to “clusters need to reach each other,” and which setup you need depends entirely on one question: do your clusters share a network, or not?
Single-network multi-cluster mesh
When all your GKE clusters live in the same VPC (or in VPCs connected well enough that Pods can reach each other’s IPs directly — the mesh’s own prerequisite is explicit: “Clusters in your mesh must have connectivity between all pods before you configure Cloud Service Mesh”), cross-cluster traffic needs nothing extra at the mesh layer. A sidecar in Cluster A can open a connection straight to a sidecar in Cluster B, because the underlying network already supports it.
Two more prerequisites from Google’s managed multi-cluster guide:
- Clusters in different projects must be registered to the same fleet host project and sit in a Shared VPC configuration on the same network.
- You create a VPC firewall rule that allows Pod traffic between the clusters: one ingress rule whose source ranges are all the clusters’ Pod CIDRs and whose targets are the clusters’ node network tags. This is a networking prerequisite, not a service-mesh-specific object.
Endpoint discovery (a sidecar in one cluster learning about endpoints in another) is turned on automatically when you enable managed Cloud Service Mesh through the fleet API. If you provisioned it another way, you enable it by setting "multicluster_mode":"connected" in the asm-options ConfigMap. Google also recommends enabling the mesh’s DNS proxy, because cross-cluster calls rely on each service’s fully qualified domain name.
Multiple-network (multi-cloud / hybrid) multi-cluster mesh
Once clusters are on genuinely separate networks — different VPCs with no direct routing, a different cloud provider, an on-prem data center — Pods in one cluster simply have no network path to Pods in the other. Sidecar-to-sidecar connections can’t happen directly anymore. This is where the east-west gateway comes in.
Context worth knowing: Google’s hybrid-mesh guide (GKE on Google Cloud plus Google Distributed Cloud on VMware or bare metal) is Preview, uses asmcli/istioctl, doesn’t support private clusters, and requires each cluster’s control plane address and gateway address to be reachable from every other cluster (Google recommends Cloud VPN to the on-prem network). The in-cluster ISTIOD control plane on GKE on Google Cloud is deprecated, as covered in the Service Mesh intro article.
What an east-west gateway is
An east-west gateway is a gateway deployment installed in each cluster, dedicated specifically to cross-cluster (“east-west,” as opposed to north-south ingress/egress) traffic to the other cluster(s) in the mesh. You install it with istioctl and the gen-eastwest-gateway.sh script, and each one is tagged with a network identifier (for example NETWORK_1 for a GKE cluster, NETWORK_2 for a cluster on another network).
Because the clusters are on separate networks, every service meant to be reachable mesh-wide (*.local) must be exposed on the east-west gateway in both clusters — it’s the only path between them, so anything not exposed there is simply unreachable from the other side.
How traffic actually gets through safely
- The east-west gateway is publicly reachable on the internet by default — which is why Google’s own guidance recommends authorized networks and VPC firewall rules to restrict access in production rather than leaving it fully open.
- Despite being internet-facing, the gateway doesn’t hand out access to anyone who finds it: services behind it can only be reached by callers presenting a trusted mTLS certificate and workload identity — the same protection from the previous article, carried across the network boundary rather than dropped at it.
- In the hybrid setup, running
asmcli create-mesh FLEET_PROJECT_ID KUBECONFIG_1 KUBECONFIG_2enables endpoint discovery between the clusters — this is what lets a Service in Cluster A actually learn about matching endpoints running in Cluster B, the mesh-level counterpart of what multi-cluster Services (MCS) does at the plain-Kubernetes level.
Single-network vs. multi-network, side by side
| Single network | Multiple networks (multi-cloud/hybrid) | |
|---|---|---|
| Direct Pod-to-Pod IP connectivity | Yes | No |
| Extra component needed | None (just a firewall rule allowing Pod CIDRs between clusters) | East-west gateway, in each cluster |
| How services are exposed cross-cluster | Automatic, if connectivity exists | Must be explicitly exposed on the east-west gateway |
| Security model for cross-cluster calls | mTLS (same as same-cluster) | mTLS, enforced at the gateway since it’s otherwise public |
| Endpoint discovery | Automatic when managed mesh is enabled via the fleet API | Needs explicit setup (asmcli create-mesh) |
Exam Takeaways
- The mesh’s own hard prerequisite: Pod-to-Pod connectivity between clusters must already exist before you configure Cloud Service Mesh across them.
- Single-network multi-cluster mesh needs no extra gateway component — sidecars connect directly, since the underlying network already allows it.
- A VPC firewall rule allowing the clusters’ Pod CIDRs to reach each other’s nodes is still needed — a networking prerequisite, separate from the mesh config itself. Clusters in different projects need the same fleet host project and a Shared VPC.
- With managed Cloud Service Mesh enabled through the fleet API, cross-cluster endpoint discovery is automatic.
- Multiple-network (multi-cloud/hybrid) setups require an east-west gateway installed in each cluster, purpose-built for cross-cluster traffic.
- Services must be explicitly exposed on the east-west gateway (
*.local) to be reachable from another network — nothing crosses automatically. - The east-west gateway is public-facing by default but still enforces mTLS + workload identity for anything it fronts — being internet-reachable isn’t the same as being open.
asmcli create-meshsets up cross-cluster endpoint discovery for multi-network meshes — the mesh-layer counterpart to what MCS does for plain Kubernetes Services.