Fleet Concepts & Hub Membership — Mô Hình Tổ Chức Multi-Cluster

Tại Sao Quan Trọng Trong Production

Trước khi Fleet tồn tại, quản lý nhiều GKE clusters là chuỗi thao tác thủ công: cấu hình kubeconfig cho từng cluster, thiết lập RBAC riêng biệt, deploy workload lên từng cluster độc lập, monitor từng cluster bằng dashboard khác nhau. Khi số cluster vượt qua ngưỡng mà một platform team có thể quản lý thủ công (thường là 5–10 clusters), hệ thống bắt đầu drift và rủi ro tích lũy mà không ai nhận ra.

Fleet giải quyết bài toán này không phải bằng cách đơn giản hóa operations mà bằng cách cung cấp một abstraction layer thống nhất phía trên các cluster riêng lẻ. Hiểu Fleet ở mức conceptual không đủ cho production — bạn cần biết fleet hoạt động như thế nào về mặt kỹ thuật để hiểu tại sao một feature hoạt động, tại sao nó không hoạt động, và tại sao một số quyết định thiết kế của bạn sẽ không được fleet hỗ trợ.

Mô Hình Nội Tại của Fleet

Fleet Là Gì Về Mặt Kỹ Thuật

Fleet không phải là một service riêng biệt chạy ở đâu đó trong GCP. Fleet là một tổ hợp logical được định nghĩa bởi một Google Cloud project làm fleet host project, và các Membership resource — mỗi Membership đại diện cho một cluster được đăng ký vào fleet đó.

Theo Google Cloud Fleet Management documentation: "Fleets are a Google Cloud concept for logically organizing clusters and other resources, letting you use and manage multi-cluster capabilities and apply consistent policies across your systems."

Điều quan trọng cần hiểu ngay từ đầu: Fleet không tạo ra một control plane tập trung mới cho Kubernetes. Mỗi cluster vẫn có control plane riêng, vẫn là một Kubernetes cluster độc lập. Fleet là một lớp orchestration phía trên, cho phép quản lý tập trung thông qua GCP APIs.

Hub Project và Cấu Trúc Hierarchy

Mỗi Google Cloud project có thể là fleet host của duy nhất một fleet (hoặc không có fleet nào). Đây là ràng buộc thiết kế quan trọng:

GCP Organization
├── project-A (fleet host → Fleet Alpha)
│   ├── Membership: cluster-prod-us-east1
│   ├── Membership: cluster-prod-eu-west1
│   └── Membership: cluster-prod-asia-east1
├── project-B (không phải fleet host)
│   └── cluster-dev-us-central1 (thành viên của Fleet Alpha)
└── project-C (fleet host → Fleet Beta)
    └── Membership: cluster-staging-us-central1

Một cluster thuộc một project nhất định có thể được đăng ký vào fleet của một project khác. Đây là pattern phổ biến: tạo một project riêng làm fleet host (thường gọi là "hub project" hoặc "platform project"), và các cluster từ các team projects khác nhau đều đăng ký vào fleet này.

Ràng buộc exclusivity là điều quan trọng nhất cần nắm: "Fleet-aware resources can only be members of a single fleet at any given time." Một cluster không thể thuộc hai fleet cùng lúc. Nếu muốn chuyển cluster sang fleet khác, phải unregister khỏi fleet hiện tại trước.

Membership Resource — Đơn Vị Cơ Bản

Khi bạn đăng ký một cluster vào fleet, GCP tạo một Membership resource trên hub project. Đây là một GCP resource (không phải Kubernetes resource) với format:

projects/{FLEET_HOST_PROJECT}/locations/global/memberships/{MEMBERSHIP_ID}

Membership resource chứa:

• Authority: OIDC issuer URL của cluster, dùng cho Fleet Workload Identity
• Endpoint: Kết nối đến cluster API server (GKE endpoint hoặc on-prem endpoint)
• State: Trạng thái kết nối hiện tại (REGISTERED, READY, DISCONNECTED...)
• Labels: Metadata phân loại cluster trong fleet

Membership resource này là "bằng chứng tư cách thành viên" của cluster trong fleet. Khi bạn enable một fleet-feature (như Config Sync, Multi-Cluster Services), GCP nhìn vào membership để biết cluster nào cần được cấu hình.

Connect Agent — Cầu Nối Kỹ Thuật

Đối với GKE clusters trên Google Cloud, kết nối giữa fleet hub và cluster được thực hiện thông qua GKE's native connectivity. Nhưng đối với các cluster chạy outside Google Cloud (on-premises, other clouds, bare metal), Connect Agent là thành phần bắt buộc.

Connect Agent là một Pod chạy trên cluster được đăng ký. Nó:

1. Thiết lập outbound kết nối từ cluster đến Google Cloud, không yêu cầu inbound connectivity (không cần public IP trên API server)
2. Duy trì persistent connection qua HTTP/2 tunnels đến Google Fleet APIs
3. Xử lý bi-directional traffic qua tunnel: kubectl commands từ Cloud Console/Cloud SDK đến cluster API server, và cluster status updates từ cluster về hub
4. Hỗ trợ kết nối qua NAT, proxies, VPNs, và Cloud Interconnect

Cho GKE clusters, Connect Gateway service xử lý authentication và routing, cho phép kubectl commands đến cluster mà không cần kubeconfig với cluster endpoint trực tiếp. Thay vào đó, bạn authenticate với Google Cloud và Connect Gateway proxy request đến đúng cluster.

# Lấy credentials thông qua Connect Gateway (không cần cluster IP)
gcloud container fleet memberships get-credentials MEMBERSHIP_ID \
    --location global \
    --project FLEET_HOST_PROJECT

Các Nguyên Tắc Thiết Kế Cốt Lõi

Namespace Sameness

Đây là nguyên tắc quan trọng nhất mà nhiều feature của fleet phụ thuộc vào: "Namespaces with the same name in different clusters are considered the same by many fleet features."

Ý nghĩa thực tế: nếu cluster-A và cluster-B đều có namespace payments, fleet coi chúng là cùng namespace. Multi-Cluster Services sẽ route traffic đến Service cùng tên trong cùng namespace xuyên clusters. Policy Controller có thể apply cùng policy cho cùng namespace xuyên clusters.

Điều này có implications sâu xa cho cluster design:

Implications tốt:

• Cùng một application deployment manifest có thể được apply lên mọi cluster mà không cần sửa namespace reference
• Traffic routing xuyên cluster (MCS) hoạt động tự nhiên dựa trên namespace + service name
• Policy enforcement nhất quán theo namespace xuyên fleet

Implications cần chú ý:

• Namespace naming collision ngoài ý muốn giữa các teams trên các clusters có thể tạo ra unexpected MCS routing
• Teams phải coordinate namespace naming conventions xuyên toàn fleet
• Workloads trong cùng namespace trên các clusters khác nhau phải được quản lý với cùng security context (namespace sameness giả định cùng policy)

Identity Sameness

Identity sameness nghĩa là workload có cùng Kubernetes Service Account (KSA) trong cùng namespace xuyên clusters được coi là cùng identity trong fleet context. Fleet Workload Identity (sẽ giải thích chi tiết ở Chapter 2) xây dựng trên nguyên tắc này.

Hệ quả: bạn không cần cấu hình IAM bindings riêng cho "cluster-A/namespace/ksa" và "cluster-B/namespace/ksa". Fleet Workload Identity cho phép một IAM binding duy nhất cover cùng identity xuyên mọi cluster trong fleet.

High Trust Model

Theo documentation, fleet hoạt động theo high trust model: "Administrators of any member in a fleet can potentially affect the operations of services in other members."

Điều này ngụ ý rằng fleet không phải là cơ chế cách ly mạnh. Nếu bạn cần strong isolation giữa các teams hoặc tenants, đừng đặt tất cả vào một fleet. Fleet là phù hợp cho:

• Tập hợp clusters thuộc cùng tổ chức với mutual trust
• Environments mà một platform team trung tâm có quyền admin xuyên tất cả

Fleet không phải là isolation boundary phù hợp cho:

• Multi-tenant SaaS với independent customers
• Clusters có compliance requirements hoàn toàn khác nhau
• Situations cần strict blast radius containment

Team Scopes — Phân Chia Fleet Theo Teams

Fleet scope ở mức cluster là quá coarse-grained cho organizations có nhiều teams. Team scopes là cơ chế phân chia fleet thành các sub-groupings gán cho specific application teams.

Một team scope bao gồm:

• Tập hợp clusters trong fleet mà team có access
• Tập hợp namespaces (Fleet namespaces) mà team quản lý

# Team scope definition (Fleet API)
# Team "payments" chỉ có access đến cluster prod-us và prod-eu
# và chỉ quản lý namespace "payments" và "payments-infra"

Với team scopes, fleet RBAC (xem Chapter 8) có thể grant permissions ở mức team scope thay vì toàn fleet, giảm blast radius của admin errors và thực hiện principle of least privilege ở fleet level.

Team scopes cũng cho phép selective namespace sameness adoption — không phải toàn bộ fleet phải áp dụng namespace sameness, chỉ những namespaces nằm trong fleet namespace scope mới được coi là "same" xuyên clusters.

Fleet-Enabled Features và Lifecycle

Khi cluster được đăng ký vào fleet, các fleet features không tự động được enable. Mỗi feature phải được explicitly enable trên fleet (và thường trên từng cluster):

# Enable Config Sync cho fleet
gcloud container fleet config-management enable \
    --project=FLEET_HOST_PROJECT

# Enable Config Sync cho specific cluster
gcloud container fleet config-management apply \
    --membership=MEMBERSHIP_ID \
    --config=config.yaml \
    --project=FLEET_HOST_PROJECT

Mỗi fleet feature (Config Sync, Policy Controller, Multi-Cluster Services, ASM...) có:

• Feature Controller chạy trong GCP control plane (phía Google, không trực tiếp visible)
• Feature-specific agents chạy trên member clusters (visible dưới dạng pods trong system namespaces)
• Feature state được track trong Membership resource

Lifecycle của fleet feature enrollment:

Enable Feature on Fleet → Feature Controller provisions agents → 
Agents deployed on member clusters → Feature operational → 
Monitor feature state via Fleet API

Cluster Registration Internals

GKE Auto-Registration

GKE clusters được tạo với --fleet-project flag sẽ tự động đăng ký vào fleet khi cluster creation hoàn thành. Quá trình này:

1. GKE API nhận cluster creation request với fleet project
2. Sau khi cluster nodes ready, GKE tự động gọi Fleet Registration API
3. Membership resource được tạo trên fleet host project
4. Connect Agent (nếu cần) được deploy lên cluster

Manual Registration

Clusters không tự động đăng ký (on-prem, other cloud, GKE thiếu --fleet-project flag) cần manual registration:

gcloud container fleet memberships register MEMBERSHIP_NAME \
    --gke-cluster=LOCATION/CLUSTER_NAME \
    --enable-workload-identity \
    --project=FLEET_HOST_PROJECT

Lệnh này:

1. Tạo Membership resource trên hub project
2. Configure cluster với fleet credentials
3. Deploy Connect Agent nếu cluster là non-GKE
4. Configure OIDC issuer trong Membership authority (cần cho Fleet Workload Identity)

Unregistration và Cleanup

Unregistering cluster không xóa resources trên cluster — chỉ xóa Membership resource trên hub project và disable fleet features. Cluster vẫn tiếp tục chạy. Resources được deploy bởi fleet features (như Config Sync reconciler pods) phải được cleanup thủ công hoặc tự động tùy theo feature.

Constraints và Giới Hạn Thực Tế

Số lượng membership trong một fleet: Google không publish giới hạn cứng tuyệt đối, nhưng fleet architecture được thiết kế cho tens-to-thousands clusters. Thực tế production, fleet với 100+ clusters là phổ biến.

Project constraint: Một project = một fleet. Nếu bạn cần phân chia fleet theo business unit, bạn cần nhiều fleet host projects khác nhau.

Cluster exclusivity: Cluster chỉ thuộc một fleet tại một thời điểm. Migration sang fleet khác cần downtime window (unregister + re-register).

Location: Membership resource được tạo ở global location (không phải regional), đây là lý do Fleet features có thể aggregate thông tin từ clusters ở nhiều regions mà không cần region-specific endpoints.

Non-GKE clusters: Clusters chạy outside GCP (on-premises, AWS EKS, Azure AKS) có thể join fleet nhưng một số fleet features chỉ support GKE (ví dụ: Fleet Workload Identity với GKE Integration cần certain cluster configurations).

Mental Model Đúng Để Reason Về Fleet

Hãy nghĩ Fleet như một directory service cho clusters, không phải là một control plane tập trung:

• Directory: Fleet track clusters và metadata của chúng (membership resources)
• Policy enforcement: Fleet distribute policies đến clusters (qua Config Sync, Policy Controller)
• Identity federation: Fleet provide unified identity layer (Fleet Workload Identity)
• Service mesh: Fleet enable cross-cluster communication (MCS, MCI)

Fleet không execute workloads, không route application traffic directly. Nó là coordination layer cho các specialized sub-systems. Mỗi sub-system (Config Sync, MCS, Policy Controller...) có cơ chế riêng và fleet chỉ là "glue" kết nối chúng.

Khi troubleshoot fleet issues, luôn hỏi: "Vấn đề này thuộc về fleet layer hay thuộc về specific feature layer?" Fleet layer thường là Membership registration, Fleet IAM, Connect Agent connectivity. Feature layer là Config Sync reconciliation failures, MCS DNS issues, etc.

Ví Dụ Production: Fleet Topology Cho Enterprise

Một enterprise với nhiều teams thường thiết kế fleet topology như sau:

Platform Fleet (hub: platform-project)
├── prod-us-east1-cluster (team: payments, infra, auth)
├── prod-eu-west1-cluster (team: payments, infra)
├── prod-asia-east1-cluster (team: payments)
├── staging-us-central1-cluster (all teams)
└── dev-us-central1-cluster (all teams)

Fleet Namespaces (team scopes):
├── Team "payments": namespaces [payments, payments-workers]
│   → Access to: prod-us, prod-eu, prod-asia, staging, dev
├── Team "auth": namespaces [auth, oauth]
│   → Access to: prod-us, staging, dev
└── Team "infra": namespaces [monitoring, logging, cert-manager]
    → Access to: all clusters

Thiết kế này thỏa mãn:

• Namespace sameness: payments namespace trên mọi cluster là cùng một team
• Team isolation: auth team không có fleet RBAC access đến payments namespaces
• Config distribution: Config Sync deploy payments config đến clusters thuộc payments team scope

References

• Fleet Concepts
• Fleet Registration
• Connect Gateway
• Fleet Scopes and Team Management