Skip to content

Chương 18: GKE Fleet Management & Kiến Trúc Multi-Cluster

Tại Sao Chương Này Quan Trọng

Không có production GKE nào dừng lại ở một cluster duy nhất. Các tổ chức vận hành nhiều clusters vì nhiều lý do kỹ thuật có căn cứ: cách ly môi trường (dev/staging/prod), phân tán địa lý để giảm latency, blast radius containment khi failure, tuân thủ data residency, và đơn giản là Kubernetes cluster có giới hạn scale nhất định mà nhiều cluster cùng hoạt động sẽ vượt qua được.

Vấn đề là khi số cluster tăng từ 3 lên 30, từ 30 lên 300 — không thể quản lý thủ công. Nếu không có abstraction layer phù hợp, platform team sẽ đối mặt với:

  • Config drift: Mỗi cluster có SecurityContext policy khác nhau, NetworkPolicy thiếu, RBAC binding lạc lõng
  • Identity fragmentation: Workload trên cluster A không thể authenticate với cluster B mà không có credential riêng
  • Service connectivity mờ đục: Traffic cross-cluster phải đi qua external LoadBalancer hoặc VPN, không có service discovery native
  • Operational overhead không scale: Upgrade 50 clusters tay không khác gì tra tấn

GKE Fleet Management là câu trả lời của Google cho bài toán này. Chương này đi sâu vào cơ chế nội tại của từng component trong fleet ecosystem — không phải để giới thiệu feature, mà để bạn hiểu tại sao mỗi thứ được thiết kế như vậy và khi nào thì chúng không hoạt động như kỳ vọng.

Điều Kiện Tiên Quyết

  • Chương 5–17: Toàn bộ GKE internals, networking, multi-tenancy
  • Workload Identity Federation (Chương 14 nếu có, hoặc kiến thức về OIDC/WIF)
  • GitOps fundamentals (khái niệm pull-based reconciliation)
  • OPA/Gatekeeper cơ bản là có lợi nhưng không bắt buộc

Mức Độ Sâu

4/5 — Tập trung vào cơ chế hoạt động bên trong và production decision-making. Đây là kiến thức platform engineering layer, không phải application layer.


Các Chủ Đề Con

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

Tại sao Fleet không chỉ là "grouping label" mà là một abstraction layer có cơ chế thực sự:

  • Fleet là gì về mặt kỹ thuật: hub project, membership resource, Connect Agent
  • Cơ chế đăng ký cluster: GKE auto-registration vs manual registration
  • Membership resource lifecycle và trạng thái kết nối
  • Các nguyên tắc thiết kế: namespace sameness, identity sameness, exclusivity
  • Fleet host project constraints và isolation model
  • Team scopes: chia nhỏ fleet cho nhiều teams

2. Fleet Workload Identity — Định Danh Thống Nhất Xuyên Cluster

Cơ chế identity hoạt động như thế nào khi workload cần authenticate đến Google Cloud services từ bất kỳ cluster nào trong fleet:

  • Giới hạn của per-cluster Workload Identity: cùng pool, khác cluster nhưng IAM không phân biệt
  • Fleet Workload Identity pool: format FLEET_PROJECT_NUMBER.global.id.goog
  • OIDC token structure và principal identifier xuyên cluster
  • KSA-to-GSA binding với fleet context
  • Cách Fleet WI giải quyết cross-cluster identity một cách deterministic
  • Khi nào dùng fleet WI vs per-cluster WI

3. Config Sync Architecture — GitOps Engine Bên Trong

Đây là phần kỹ thuật nhất của Config Sync: cách RootSync và RepoSync hoạt động bên dưới lớp abstraction:

  • RootSync vs RepoSync: scope, quyền hạn, khi nào dùng cái nào
  • Reconciler Pod: thành phần nào làm gì, vòng đời reconciliation loop
  • Importer, Parser, Applier: pipeline xử lý config từ source đến cluster
  • Conflict detection và drift remediation
  • Sync failure modes: network, auth, parse error, apply conflict
  • Hierarchical namespace controller integration

4. Config Sync Sources & Hierarchical Repository — Tổ Chức Cấu Hình Ở Scale

Config Sync đọc từ đâu và tổ chức repository thế nào cho fleet với hàng chục clusters:

  • Git source: authentication, branch/tag/commit pinning, polling interval
  • OCI source: image format requirements, layer structure, update mechanism
  • Helm source: chart rendering pipeline bên trong Config Sync, giới hạn
  • Hierarchical vs unstructured repository: khi nào hierarchy là lựa chọn đúng
  • Pattern tổ chức: cluster-scoped config, namespace-scoped config, app config
  • Kết hợp RootSync (cluster admin) và RepoSync (app team) delegation model

5. Policy Controller — OPA Constraint Engine Trên Fleet

Cơ chế Policy Controller (dựa trên OPA/Gatekeeper) và cách nó thực thi policy trên toàn fleet:

  • ConstraintTemplate và Rego policy: cách định nghĩa logic kiểm tra
  • Constraint CRD: instantiation, scope, parameters
  • Audit mode vs Enforce mode: tại sao audit không chỉ là "test mode" mà là production pattern
  • Admission webhook integration: thời điểm policy được evaluate trong request lifecycle
  • Fleet-level policy distribution qua Config Sync
  • Violation reporting và remediation workflow

6. Multi-Cluster Services (MCS) — Service Discovery Xuyên Cluster

Cơ chế nội tại của Multi-Cluster Services: làm thế nào một Service trên cluster A có thể được gọi từ cluster B mà không cần external LoadBalancer:

  • ServiceExport và ServiceImport: resource lifecycle, controller reconciliation
  • MCS controller architecture: điều phối ở fleet hub level
  • Cloud DNS integration: record tự động được tạo như thế nào
  • DNS name format: <service>.<namespace>.svc.clusterset.local
  • Virtual IP allocation cho ServiceImport
  • Cross-cluster endpoint propagation: độ trễ, consistency model
  • Constraints: fleet membership bắt buộc, same-namespace requirement

7. Multi-Cluster Ingress & Multi-Cluster Gateway — Global Load Balancing

Hai thế hệ giải pháp expose traffic đến multi-cluster backend: legacy MCI và modern Gateway API:

  • Multi-Cluster Ingress: config cluster pattern, MultiClusterIngress/MultiClusterService CRDs
  • Cơ chế Global External Load Balancer tạo NEGs xuyên cluster
  • Config cluster: single point of truth vs single point of failure
  • Multi-Cluster Gateway: GatewayClass gke-l7-global-external-managed-mc, HTTPRoute xuyên cluster
  • Sự khác biệt cơ bản giữa MCI và MCG: centralized vs distributed configuration
  • Traffic routing, health checks, affinity xuyên clusters
  • Khi nào dùng cái nào

8. Fleet RBAC & Fleet Observability — Governance Xuyên Cluster

Hai khía cạnh của fleet governance: ai được làm gì, và nhìn thấy gì đang xảy ra:

  • Fleet IAM → Kubernetes RBAC: cơ chế propagation, IAM roles được map sang ClusterRoleBindings
  • Team scopes: RBAC cho namespace subset thay vì toàn cluster
  • Fleet Observability: cách metrics được aggregated từ nhiều clusters vào Cloud Monitoring
  • Fleet-level dashboards: cấu trúc và giới hạn
  • Cross-cluster log correlation

9. Config Controller — Quản Lý GCP Resources Qua Kubernetes CRDs

Config Controller là fully-managed GKE cluster cài sẵn Config Connector và Config Sync, dùng để quản lý Google Cloud resources bằng Kubernetes manifest:

  • Config Connector (KCC): cơ chế CRD-to-GCP-resource reconciliation
  • Controller loop: desired state → GCP API call → actual state → status update
  • Deletion protection và resource abandon
  • Config Controller vs standalone KCC: sự khác biệt về managed service model
  • Tại sao pattern này (Kubernetes quản lý cloud resources) có lợi thế nhất định so với Terraform

10. Anthos Service Mesh Multi-Cluster — Mesh Xuyên Cluster

Cách ASM (dựa trên Istio) mở rộng service mesh ra ngoài ranh giới một cluster:

  • Trust federation: cơ chế SPIFFE identity xuyên cluster
  • Istiod và cross-cluster service discovery
  • Endpoint discovery: cách Pilot/Istiod biết về endpoints ở cluster khác
  • mTLS xuyên cluster: certificate chain và trust bundle exchange
  • Fleet-based ASM enrollment: managed vs in-cluster control plane
  • Traffic management xuyên cluster: LocalityLoadBalancing, failover

11. Network Connectivity Center — Hub-and-Spoke Networking

NCC giải quyết bài toán kết nối mạng ở enterprise scale: nhiều sites, nhiều VPCs, nhiều clouds:

  • Hub và spoke model: NCC không phải VPN concentrator mà là routing framework
  • Spoke types: VPC spokes, hybrid spokes (VPN, Interconnect, Router Appliance)
  • Data transfer giữa spokes: cơ chế route re-advertisement
  • Site-to-site data transfer: dùng Google backbone thay vì Internet
  • NCC với GKE: multi-region cluster connectivity pattern
  • Giới hạn và constraints: ASN requirements, IPv4 only cho hybrid spokes

Key Concepts Tóm Tắt

ConceptCơ Chế Cốt LõiFile
Fleet MembershipKubernetes resource trên hub project, Connect Agent tunnel01
Fleet Workload IdentityOIDC pool tại fleet level, không phụ thuộc cluster02
RootSync/RepoSyncReconciler pods pull từ source, apply qua server-side apply03
Config Sync SourcesGit/OCI/Helm, polling vs webhook trigger04
Policy ControllerOPA Gatekeeper webhook + audit controller05
MCS ServiceExportFleet controller tạo Cloud DNS records, ServiceImport CRD06
Multi-Cluster IngressConfig cluster + GCLB NEGs xuyên clusters07
Fleet RBACFleet IAM roles → Kubernetes ClusterRoleBinding08
Config Controller/KCCCRD spec → GCP API reconciliation loop09
ASM Multi-ClusterSPIFFE trust federation, Pilot cross-cluster discovery10
NCCHub orchestrates spoke route re-advertisement11

Learning Path

Nếu bạn đang thiết kế fleet architecture từ đầu:

  1. Chương 1: Fleet Concepts — nền tảng conceptual
  2. Chương 2: Fleet Workload Identity — giải quyết identity trước
  3. Chương 3: Config Sync Architecture — config management engine
  4. Chương 5: Policy Controller — guardrails

Nếu bạn đang debug multi-cluster connectivity:

  1. Chương 6: MCS — east-west traffic
  2. Chương 7: MCI/MCG — north-south traffic
  3. Chương 11: NCC — network layer

Nếu bạn đang xây dựng platform governance:

  1. Chương 8: Fleet RBAC & Observability
  2. Chương 5: Policy Controller
  3. Chương 9: Config Controller

Official References