Multi-cluster Ingress & Multi-cluster Gateway — Global Load Balancing Xuyên Cluster

Vấn đề mà multi-cluster LB giải quyết

Khi bạn chạy nhiều GKE clusters ở các regions khác nhau, bạn thường cần một entry point duy nhất route traffic đến cluster gần nhất hoặc available nhất. Các approaches thô sơ — DNS round-robin, manual routing — không xử lý được failover tự động, weighted routing theo health status, hay latency-based selection.

Multi-cluster Ingress (MCI) và Multi-cluster Gateway (MCG) giải quyết bằng cách tạo một single GCP Global Application LB với backends phân tán trên nhiều clusters và regions. Khi một cluster unavailable, traffic tự động shift sang cluster khác — toàn bộ được GCP LB xử lý mà không cần DNS change.

Hai cơ chế này phục vụ cùng mục đích nhưng thuộc hai generation của API khác nhau: MCI là legacy (maintenance mode), MCG là recommended cho hệ thống mới.

Multi-cluster Ingress (Legacy)

Kiến trúc tổng quan

MCI hoạt động theo mô hình config cluster: một cluster được chỉ định là "trung tâm điều khiển" (config cluster) và các clusters khác là member clusters.

Config Cluster
  │
  ├── MultiClusterIngress resource (định nghĩa routing)
  ├── MultiClusterService resource (định nghĩa backends)
  │
  └── MCI Controller (Google-hosted, watch config cluster)
        │ provision
        ▼
  GCP Global External Application LB
        │
        ├── NEG (us-central1) → Pods trong cluster-us
        ├── NEG (europe-west1) → Pods trong cluster-eu
        └── NEG (asia-east1) → Pods trong cluster-asia

Config cluster không nhất thiết phải xử lý production traffic — nó là control plane. Có thể là dedicated cluster chỉ để quản lý, hoặc một trong các member clusters.

Fleet — Điều kiện tiên quyết

Tất cả clusters tham gia MCI phải được đăng ký vào cùng một Fleet. Fleet là khái niệm tổ chức clusters vào một nhóm logic với shared configuration.

# Enable Fleet API
gcloud services enable gkehub.googleapis.com

# Đăng ký clusters vào fleet
gcloud container fleet memberships register cluster-us \
  --gke-cluster=us-central1/cluster-us \
  --enable-workload-identity \
  --project=my-project

gcloud container fleet memberships register cluster-eu \
  --gke-cluster=europe-west1/cluster-eu \
  --enable-workload-identity \
  --project=my-project

# Enable Multi-cluster Ingress feature với config cluster
gcloud container fleet ingress enable \
  --config-membership=cluster-us \
  --project=my-project

MultiClusterIngress và MultiClusterService CRDs

Sau khi MCI được enable, config cluster nhận hai CRDs mới:

MultiClusterService: Định nghĩa Service được expose trên nhiều clusters

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: my-mcs
  namespace: default
spec:
  template:
    spec:
      selector:
        app: my-app
      ports:
        - name: http
          protocol: TCP
          port: 8080

MultiClusterService tương đương với Kubernetes Service, nhưng áp dụng cho tất cả member clusters. Khi bạn tạo MultiClusterService, MCI controller tạo Kubernetes Service tương ứng trong tất cả member clusters.

MultiClusterIngress: Định nghĩa routing rules cho GCP Global LB

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: my-mci
  namespace: default
  annotations:
    networking.gke.io/static-ip: "mci-static-ip"
spec:
  template:
    spec:
      backend:
        serviceName: my-mcs
        servicePort: 8080
      rules:
        - host: app.example.com
          http:
            paths:
              - path: /api
                backend:
                  serviceName: api-mcs
                  servicePort: 8080

Cách MCI controller provision GCP LB

Khi MultiClusterIngress được tạo trong config cluster:

1. MCI controller (Google-hosted, watch config cluster) đọc MultiClusterIngress spec
2. Với mỗi cluster member, controller tạo NEGs trong cluster đó — NEGs chứa Pod endpoints của ứng dụng trong cluster đó
3. Controller tạo một GCP Global External Application LB với Backend Services nhận input từ NEGs của tất cả clusters
4. URL Map routing rules từ MultiClusterIngress spec được áp vào LB

Kết quả: Một IP duy nhất, một GCP LB với backends phân tán trên nhiều regions. GCP LB routing algorithm (anycast + proximity) tự động route client đến cluster gần nhất.

Constraints của MCI

• Chỉ hỗ trợ External Application LB: MCI không support Internal LB
• Yêu cầu VPC-native clusters với Workload Identity: WIF phải được enable
• Cùng project cho Shared VPC: Với Shared VPC, tất cả backend clusters phải cùng project
• Config cluster là SPOF: Nếu config cluster down, không thể thay đổi routing. Workload trên member clusters vẫn hoạt động nhưng không thể update LB config

Multi-cluster Gateway (Recommended)

Tại sao MCG tốt hơn MCI

MCG là implementation của Multi-cluster routing qua Gateway API — inherits tất cả benefits của Gateway API (role separation, expressive routing, Policy CRDs) đồng thời hỗ trợ multi-cluster backends.

Khía cạnh	MCI	MCG
API generation	Legacy (maintenance mode)	Recommended
Traffic splitting	Không hỗ trợ	Có (weight-based)
Header routing	Không	Có
Role separation	Không	Có (operator/developer)
GatewayClass	N/A	Explicit (gke-l7-*-mc)
Config cluster requirement	Bắt buộc	Vẫn cần (fleet-based)

Multi-cluster GatewayClasses

GKE cung cấp các GatewayClasses có suffix -mc cho multi-cluster scenarios:

gke-l7-global-external-managed-mc  → Global External ALB, multi-cluster
gke-l7-rilb-mc                     → Internal ALB, multi-cluster (regional)

Các GatewayClasses này chỉ available sau khi enable multi-cluster Gateway feature trong fleet:

gcloud container fleet ingress enable \
  --config-membership=projects/my-project/locations/us-central1/memberships/cluster-us

MCG setup — Cơ chế hoạt động

# Gateway được tạo trong config cluster
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: multi-cluster-gateway
  namespace: default
  annotations:
    networking.gke.io/static-ip: "mc-gateway-ip"
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: multi-cluster-cert

# ServiceImport — cầu nối từ multi-cluster service vào HTTPRoute
# ServiceImport được tạo tự động bởi Multi-cluster Services (MCS) feature
apiVersion: net.gke.io/v1
kind: ServiceImport
metadata:
  name: api-service
  namespace: default

# HTTPRoute reference ServiceImport thay vì Service
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
    - name: multi-cluster-gateway
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - group: net.gke.io
          kind: ServiceImport
          name: api-service-v1
          port: 8080
          weight: 90
        - group: net.gke.io
          kind: ServiceImport
          name: api-service-canary
          port: 8080
          weight: 10

Multi-cluster Services (MCS) — Backbone của MCG

MCG phụ thuộc vào Multi-cluster Services (MCS) feature để discover services trên các clusters:

• Service trong cluster member được "exported" qua ServiceExport CRD
• MCS controller tạo ServiceImport trong config cluster
• ServiceImport đại diện cho service đó xuyên suốt tất cả member clusters
• MCG sử dụng ServiceImport làm backend references trong HTTPRoute

# Trong mỗi member cluster: export service
apiVersion: net.gke.io/v1
kind: ServiceExport
metadata:
  name: api-service
  namespace: default

Khi ServiceExport được tạo, MCS controller propagate endpoint information lên fleet level, tạo ServiceImport trong config cluster với tất cả endpoints từ tất cả clusters.

Traffic routing trong MCG

Khi GCP Global LB nhận request:

1. Anycast routing đưa client đến PoP GCP gần nhất
2. Backend selection dựa trên URL Map rules (từ HTTPRoute compilation)
3. Trong Backend Service, các endpoints đến từ nhiều clusters (nhiều regions) được distribute dựa trên:
   • Weighted round-robin theo weight trong HTTPRoute
   • Proximity-based routing: GCP ưu tiên backends gần PoP xử lý request

Cơ chế proximity: GCP Backend Services có thể cấu hình localityLbPolicy để kiểm soát preference. Mặc định, GCP ưu tiên backends trong region gần nhất với PoP. Nếu region đó không healthy (tất cả endpoints fail health check), traffic fail-over sang region khác — automatic failover không cần DNS change.

Health check behavior trong multi-cluster

Mỗi cluster có NEG riêng. Health check từ GCP LB probe endpoints trong mỗi NEG (Pod IPs trên mỗi cluster). Nếu một cluster có ứng dụng chết (tất cả Pods fail health check), tất cả endpoints từ cluster đó bị đánh dấu unhealthy. GCP LB tự động không route traffic đến cluster đó.

Khi cluster recover, Pods restart → pass health check → NEG endpoints được mark healthy → traffic resume. Không cần manual intervention.

Failure modes và considerations

Config cluster là điểm mong manh

Cả MCI và MCG đều phụ thuộc vào config cluster để thay đổi LB configuration. Nếu config cluster down:

• Traffic hiện tại không bị ảnh hưởng: GCP LB đã được provisioned và tiếp tục hoạt động theo config cuối cùng
• Không thể thay đổi routing: Không thể update HTTPRoute, thêm backends, thay đổi health check config

Vì vậy config cluster không nên là production workload cluster quan trọng — nên có SLA cao và được bảo vệ khỏi voluntary disruptions.

Deployment lag xuyên clusters

Khi bạn deploy ứng dụng mới lên member clusters và muốn traffic shift đến version mới, có deployment lag:

1. Pods mới phải startup và pass readiness probes
2. NEG controller trong mỗi cluster phải sync new endpoints vào NEGs
3. GCP health checks phải pass cho new endpoints
4. GCP LB mới bắt đầu route traffic đến new endpoints

Tổng thời gian: 1-3 phút per cluster. Với multi-cluster deployment, cần orchestrate theo thứ tự và verify health của từng cluster trước khi proceed.

DNS và certificate planning

Global LB với multi-cluster backends cần:

• Static IP được reserved trước để DNS record có thể point đến stable IP
• Wildcard certificates nếu multi-tenant (nhiều subdomains), hoặc Certificate Manager với multiple certs
• DNS failover không cần: Vì một IP duy nhất phục vụ tất cả, DNS không cần thay đổi khi cluster failover

Đây là advantage lớn của MCG/MCI so với DNS-based routing: failover trong seconds (GCP LB level) thay vì minutes (DNS TTL).

Cross-region cost

Traffic từ GCP LB đến backends trong region khác incurs cross-region data transfer cost. Proximity-based routing giảm thiểu nhưng không loại bỏ hoàn toàn cross-region traffic — đặc biệt khi một region fails và failover xảy ra.

Cần model cost cho worst-case scenario khi một region down và toàn bộ traffic đổ vào region còn lại.

Chọn MCI hay MCG

Với hệ thống mới: MCG là lựa chọn duy nhất hợp lý. MCI đang ở maintenance mode và MCG cung cấp tất cả capabilities của MCI cộng thêm traffic splitting, header routing, và role separation từ Gateway API.

Với hệ thống đang dùng MCI: migration sang MCG là nên làm nhưng không urgent. MCI vẫn được support. Migration path: tạo MCG song song với MCI, dần shift traffic, sau đó decommission MCI.

References

• Multi-cluster Ingress Overview
• Multi-cluster Gateway Setup
• Multi-cluster Services (MCS)
• Fleet Management Overview
• ServiceExport and ServiceImport