GCP ACE: Multi-Cluster GKE Architecture — Centralized Management and the Connect Gateway
The previous article defined what a Fleet is and why sameness/trust matter. This one covers the operational side: once clusters are registered to a Fleet, how do you actually manage and reach them — especially clusters that aren’t even running on Google Cloud?
Centralized cluster management
Without Fleets, managing several clusters means switching between projects (and sometimes clouds) one at a time, each with its own console view. A Fleet gives you one place — the fleet host project — to view, monitor, debug, and manage workloads across every registered cluster, regardless of where each one actually runs (Google Cloud, AWS, Azure, or on-prem).
This is the foundation that later modules in this course build on: Config Sync pushes configuration to every fleet cluster from one source, Policy Controller enforces policy fleet-wide, and the Fleet dashboard in the console is where you see the aggregate health of all of it. Some fleet-dependent features — Multi Cluster Ingress and Cloud Service Mesh among them — carry additional cost beyond the clusters themselves, which is worth flagging before you turn them on across a large fleet.
The Connect gateway — reaching clusters you can’t reach directly
Here’s the actual architectural problem centralized management has to solve: if you have 10 clusters across 3 cloud providers and on-prem, you can’t assume direct network access (a VPN, a public endpoint) to every single one. The Connect gateway solves this by giving you a single, Google-hosted endpoint that proxies your kubectl requests to the right cluster — you authenticate once with your Google Cloud credentials, and Google routes the request to the correct fleet member.
How you use it:
# 1. See your fleet's clusters and their membership names
gcloud container fleet memberships list
# 2. Fetch a special kubeconfig that routes through the gateway
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
# 3. Use kubectl exactly as normal — the gateway handles the routing
kubectl get namespaces
The resulting kubeconfig’s server address is a connectgateway.googleapis.com URL tied to that cluster’s fleet membership — not the cluster’s own API server address. That’s the detail that makes this work for clusters with no direct network path: you’re never actually connecting straight to the cluster’s control plane. It looks like https://connectgateway.googleapis.com/v1/projects/PROJECT_NUMBER/locations/global/gkeMemberships/MEMBERSHIP_NAME — don’t hand-edit it; regenerate the kubeconfig with get-credentials instead.
Using a service account instead of your own identity:
gcloud config set auth/impersonate_service_account SA_EMAIL_ADDRESS
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
For non-GKE-on-Google-Cloud clusters, the equivalent commands are cloud-specific:
gcloud container aws clusters get-credentials CLUSTER_NAME # GKE on AWS
gcloud container azure clusters get-credentials CLUSTER_NAME # GKE on Azure
Required IAM roles
| Role | What it grants |
|---|---|
roles/gkehub.gatewayReader (Connect Gateway Reader) | Fetch the gateway kubeconfig |
roles/gkehub.gatewayAdmin (Connect Gateway Admin) | Actually run kubectl commands through the gateway — the only predefined role carrying gkehub.gateway.stream |
Streaming commands need more
kubectl exec, cp, attach, and port-forward through the gateway have extra requirements, because these are long-lived, bidirectional streams rather than simple request/response calls:
- Cluster version 1.30+ (1.31+ specifically for
port-forward). kubectlclient version 1.31+.- The
gkehub.gateway.streamIAM permission, plus standard Kubernetes RBACgetaccess topods/exec,pods/attach, andpods/portforwardon the target namespace — IAM alone isn’t enough; you need both layers to actually grant.
The Connect agent — and why GKE clusters don’t need it
For clusters outside Google Cloud (on-prem, other clouds), a Connect agent runs inside the cluster and forwards gateway requests on its behalf — it’s the thing bridging a cluster that Google Cloud otherwise has no network path to. If that agent is missing or unhealthy, gateway connections to that cluster fail.
GKE clusters on Google Cloud don’t need the Connect agent for the gateway to work — the gateway connects to the GKE cluster directly, and registration no longer installs the agent by default. This is an easy exam trap: the agent is how non-GKE fleet members are reached, not a requirement for native GKE. (One legacy wrinkle: gcloud 399.0.0 and earlier still assume the agent exists, so either upgrade gcloud or re-register with --install-connect-agent.)
Exam Takeaways
- Fleets give you one management surface (the fleet host project) across clusters running anywhere — Google Cloud, AWS, Azure, or on-prem.
- The Connect gateway exposes clusters through a Google-hosted
connectgateway.googleapis.comendpoint, so you never need direct network access (VPN, public IP) to the cluster itself. gcloud container fleet memberships get-credentials MEMBERSHIP_NAMEis the GKE-on-Google-Cloud command; AWS/Azure clusters use their own cloud-specificget-credentialsvariants.- Two distinct IAM roles matter:
gatewayReader(fetch kubeconfig) vs.gatewayAdmin(actually run commands) — don’t confuse “can get credentials” with “can execute.” - Streaming subcommands (
exec,cp,attach,port-forward) need a minimum cluster/kubectl version (1.30+/1.31+) and both IAM permission and Kubernetes RBAC — IAM alone doesn’t grant it. - The Connect agent is required for non-Google-Cloud fleet members, but not for native GKE clusters — know this distinction, it’s a common trap.
- Some fleet-enabled features (Multi Cluster Ingress, Cloud Service Mesh) carry additional cost on top of the clusters themselves.