← Back to posts
certifications 28 Oct 2026

GCP ACE: Introduction to GKE at Scale — Multi-Cluster and Fleets

gcpacecertificationkubernetesgkefleetsmulti-cluster

Everything in this series so far assumed one cluster. At real scale, that assumption breaks down fast — different regions, different environments (dev/staging/prod), different teams, sometimes different cloud providers entirely. This article opens GKE’s answer to “now I have many clusters, not one”: Fleets.

Why multi-cluster, in the first place

A single cluster is a single blast radius, a single upgrade domain, and often a single region. Organizations end up with multiple clusters for reasons that have nothing to do with choice:

The problem multi-cluster management then creates: you now have N clusters, each with its own RBAC, its own config, its own view of the world — and keeping them consistent by hand doesn’t scale past a handful.

What a GKE Fleet is

A fleet is Google Cloud’s logical grouping of clusters (and other “fleet-aware” resources) so you can apply consistent policy and use multi-cluster features across all of them at once, instead of one cluster at a time.

Key facts about fleets:

Creating a fleet and registering clusters

# Create a fleet explicitly (optional — see below)
gcloud container fleet create --display-name=my-fleet --project=FLEET_HOST_PROJECT_ID

You can skip this entirely: registering your first cluster in a project with no existing fleet creates one automatically.

GKE on Google Cloud does not auto-register — joining a fleet is a deliberate, explicit step, unlike GKE on AWS/Azure (created through the GKE Multi-Cloud API) or on-prem Google Distributed Cloud clusters, which register automatically at creation. You can make that step part of cluster creation by adding --enable-fleet:

gcloud container clusters create-auto CLUSTER_NAME --enable-fleet   # Autopilot
gcloud container clusters create CLUSTER_NAME --enable-fleet        # Standard

Or register a cluster that already exists:

# Register to the fleet in the cluster's own project
gcloud container clusters update CLUSTER_NAME --enable-fleet

# Register as a lightweight membership (lower overhead, fewer features)
gcloud container clusters update CLUSTER_NAME --enable-fleet --membership-type=LIGHTWEIGHT

# Register to a fleet hosted in a different project (needs cross-project IAM set up first)
gcloud container clusters update CLUSTER_NAME --fleet-project=PROJECT_ID_OR_NUMBER

# Convert a lightweight membership to a regular one
gcloud container clusters update CLUSTER_NAME --unset-membership-type

The cluster name becomes its membership name in the fleet, so two clusters with the same name can’t join the same fleet.

gcloud container fleet memberships list --project=PROJECT_ID
gcloud container fleet memberships describe MEMBERSHIP_NAME --project=PROJECT_ID

The exam-relevant detail here: GKE on Google Cloud clusters must be explicitly registered. Don’t assume a freshly created GKE cluster is automatically part of any fleet — it isn’t, unless you created it with --enable-fleet or registered it afterwards.

Sameness — what makes multi-cluster features possible

Fleet features work by treating identically-named objects across different clusters as the same logical thing. This is called sameness, and it comes in three flavors:

TypeWhat it means
Namespace samenessA namespace with the same name on different clusters is treated as one logical namespace across the fleet — namespace ownership needs to be consistent across clusters that share it.
Service samenessA Service with the same namespace + name on different clusters is treated as the same service — their endpoints can be merged. This underlies Cloud Service Mesh and Multi Cluster Ingress.
Identity samenessA (namespace, service account) pair is treated as a single identity across the fleet. Fleet Workload Identity Federation lets a workload use one common identity for external resources regardless of which cluster it’s running on; Cloud Service Mesh can authorize a workload once, fleet-wide.

Not every fleet feature requires sameness — Config Sync and Policy Controller (covered in a later article) can use it, for example to target a namespace across clusters, but don’t depend on it. But features like Multi Cluster Ingress and fleet Workload Identity Federation always assume it’s true. If two clusters have a namespace called payments doing completely unrelated things, and you turn on a sameness-dependent feature, you’ve just merged them conceptually — which is exactly the kind of mistake the exam likes to test.

Trust — the boundary sameness actually depends on

Sameness only makes sense between clusters that trust each other. Google’s own framing: clusters provide blast-radius, availability, and “noisy neighbor” protection between workloads — but they are not a strong isolation boundary for governance. An administrator with access to one cluster in a fleet can, through sameness features, affect services running on other member clusters.

The practical rule: clusters you don’t fully trust should live in their own, separate fleet — not as members of a fleet alongside clusters you do trust. If you still need specific services to talk across that trust boundary, you authorize those individual services explicitly, rather than putting everything in one fleet and hoping RBAC alone contains the blast radius.

Exam Takeaways

Sources

↗ LinkedIn