Cơ Chế Upgrade Cluster GKE: Control Plane, Node Pool & Autopilot

Upgrade là quá trình có thứ tự cứng, không phải atomic operation

Một trong những hiểu nhầm phổ biến nhất về GKE upgrade là coi nó như một operation đơn lẻ. Thực tế, upgrade là một chuỗi các bước có thứ tự cứng:

1. Control plane upgrade (Google-managed)
   └── Zonal: downtime ngắn trong khi single master upgrade
   └── Regional: rolling, từng replica một, high available

2. System node pool upgrade (nếu có)
   └── Các node pool chứa system components

3. User node pool upgrades (theo thứ tự xác định)
   └── Từng pool một (mặc định) hoặc concurrent (preview)
   └── Trong mỗi pool: từng node một hoặc theo batch

Hiểu thứ tự này là điều kiện để diagnose "tại sao cluster upgrade đang ở bước nào" và "tại sao bị stuck".

Control plane upgrade mechanics

Zonal cluster vs Regional cluster

Zonal cluster có một control plane replica duy nhất. Trong thời gian upgrade, control plane trở nên không available:

Không thể deploy workload mới
Không thể thay đổi cluster configuration
Không thể kubectl apply hoặc kubectl scale
Workload đang chạy KHÔNG bị ảnh hưởng — pods tiếp tục chạy, services tiếp tục serve traffic

Thời gian downtime control plane của zonal cluster thường dưới 10 phút, nhưng có thể kéo dài hơn tùy version.

Regional cluster có nhiều control plane replicas phân bổ across multiple zones trong cùng region. Upgrade diễn ra rolling, từng replica một. Không có thời điểm nào mà control plane hoàn toàn unavailable. Đây là lý do tại sao regional cluster là bắt buộc cho production nếu team cần zero control plane downtime trong upgrade.

bash

# Tạo regional cluster (3 control plane replicas)
gcloud container clusters create CLUSTER_NAME \
    --region=us-central1 \
    --release-channel=regular

# Tạo zonal cluster (1 control plane replica)
gcloud container clusters create CLUSTER_NAME \
    --zone=us-central1-a \
    --release-channel=regular

Control plane upgrade sequence

Khi control plane upgrade xảy ra (auto hoặc manual), GKE:

Provision một control plane replica mới với version mới
Chờ new replica healthy và synced với etcd
Redirect traffic từ old replica sang new replica
Terminate old replica
Lặp cho mọi replica (regional cluster)

Trong giai đoạn này, nodes tiếp tục chạy version cũ của kubelet. Đây là trạng thái hợp lệ theo version skew policy (kubelet có thể lag control plane 1–2 minor versions).

Tại sao không thể skip minor version

GKE enforce constraint này cứng nhắc:

bash

# Cluster đang chạy 1.28.x
# Có thể upgrade lên:
gcloud container clusters upgrade CLUSTER_NAME --master --cluster-version=1.29.x  # OK
gcloud container clusters upgrade CLUSTER_NAME --master --cluster-version=1.30.x  # ERROR

Error message: "Cannot upgrade control plane from version 1.28.x to 1.30.x; must upgrade through intermediate versions"

Lý do kỹ thuật: Kubernetes API objects, etcd schema, và controller behavior có thể thay đổi giữa các minor versions. Skip version đồng nghĩa với skip migration logic, dẫn đến data corruption hoặc undefined behavior trong etcd.

Auto-upgrade vs Manual upgrade

Auto-upgrade: cơ chế mặc định

Auto-upgrade là hành vi mặc định trên GKE. Control plane luôn được tự động upgrade và không thể disable. Node pools có auto-upgrade bật mặc định nhưng có thể disable (không khuyến nghị cho production do security reason).

Cơ chế trigger auto-upgrade:

GKE xác định "recommended version" cho channel
→ Cluster đang chạy version cũ hơn recommended
→ GKE kiểm tra maintenance window: có phải đang trong allowed window không?
→ Có maintenance exclusion đang active không?
→ Cluster disruption budget có cho phép không?
→ Nếu tất cả checks pass → bắt đầu upgrade sequence

Advance notice cho auto-upgrade: Theo tài liệu GCP, GKE đảm bảo patch version phải available ít nhất 1 tuần trước khi trở thành auto-upgrade target. Minor version yêu cầu 4–8 tuần advance notice tùy channel. Team có đủ thời gian để thực hiện manual upgrade trước khi auto-upgrade xảy ra.

Manual upgrade

Manual upgrade bypass maintenance window và exclusion:

bash

# Manual upgrade control plane
gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --cluster-version=1.29.5-gke.1091000 \
    --zone=us-central1-a

# Manual upgrade node pool
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=default-pool \
    --cluster-version=1.29.5-gke.1091000 \
    --zone=us-central1-a

Khi nào dùng manual upgrade:

Muốn upgrade trước khi auto-upgrade window bắt đầu
Cần upgrade vào một thời điểm cụ thể (ví dụ: ngay sau khi hoàn thành regression testing)
Emergency security patch cần apply ngay, không thể đợi maintenance window

Lưu ý quan trọng: Manual upgrade node pool không tôn trọng cluster disruption budget nhưng vẫn tôn trọng PodDisruptionBudget của workload.

Verify version trước khi upgrade

bash

# Xem versions available cho channel
gcloud container get-server-config \
    --zone=us-central1-a \
    --format="yaml(channels)"

# Xem version hiện tại của cluster
gcloud container clusters describe CLUSTER_NAME \
    --zone=us-central1-a \
    --format="value(currentMasterVersion,currentNodeVersion)"

Node pool upgrade sequencing

Thứ tự mặc định: sequential, một pool tại một thời điểm

Theo mặc định, GKE upgrade từng node pool một, không upgrade song song. Trong một cluster có 5 node pools:

Pool A upgrade → hoàn thành → Pool B upgrade → hoàn thành → ...

Điều này có nghĩa là tổng thời gian upgrade cluster tỷ lệ thuận với số lượng node pools và kích thước của chúng. Cluster với 100 nodes chia thành 5 pools của 20 nodes mỗi pool sẽ upgrade chậm hơn cluster có 1 pool 100 nodes.

Implication: Thiết kế nhiều node pools nhỏ có trade-off: flexibility cao hơn nhưng upgrade duration dài hơn.

Concurrent node pool upgrades (Preview)

GKE có tính năng preview cho phép upgrade nhiều node pools đồng thời. Điều này có thể giảm đáng kể tổng thời gian upgrade cho cluster nhiều pools.

bash

# Enable concurrent upgrades (preview feature)
gcloud container clusters update CLUSTER_NAME \
    --enable-concurrent-node-pool-upgrade \
    --location=LOCATION

Trade-off khi dùng concurrent upgrade:

Nhanh hơn đáng kể (có thể giảm 60-80% thời gian cho cluster nhiều pools)
Nhưng disruption xảy ra đồng thời trên nhiều pools — nếu workload phân bổ across pools, impact có thể lớn hơn
Cần đảm bảo cluster có đủ capacity để tolerate drain đồng thời

Upgrade sequencing trong fleet nhiều clusters

Khi quản lý nhiều clusters (ví dụ: 10 clusters cho các teams khác nhau), cần strategy để không upgrade tất cả cùng lúc:

Cluster disruption budget (xem chi tiết tại Chương 15, bài 04) cho phép giới hạn số lượng clusters trong fleet đang upgrade đồng thời. Điều này đặc biệt quan trọng khi dùng GKE Fleet.

Pattern khuyến nghị cho fleet:

1. Upgrade staging/dev clusters trước → validate
2. Upgrade 10% production clusters → monitor 24h
3. Upgrade 50% production clusters → monitor 24h  
4. Upgrade 100% production clusters

Standard cluster upgrades: đặc điểm và control

Upgrade một node trong pool

Khi node pool bắt đầu upgrade (dù surge hay blue-green), cho từng node:

Cordon — Node bị mark là unschedulable. Scheduler không schedule pods mới lên node này.
Drain — GKE evict tất cả pods đang chạy trên node. Pods được evict theo thứ tự ưu tiên (priority), tôn trọng PodDisruptionBudget và termination grace period.
Upgrade — Node được recreate với new image/version. Với surge upgrade, đây là node mới; với in-place (maxUnavailable), đây là recreate cùng node.
Uncordon — Node được mark là schedulable trở lại.

Hard time limit cho drain: GKE sẽ đợi tối đa 1 giờ cho drain hoàn thành (tôn trọng PDB và termination grace period). Sau 1 giờ, remaining pods bị force evicted bất kể PDB.

Đây là source của nhiều production incidents: team có PDB minAvailable: 100% và pods với terminationGracePeriodSeconds: 3600. Pod bị force kill sau 1 giờ trong khi đang xử lý long-running job.

Node upgrade trong multi-zone node pool

Đối với node pool trải rộng nhiều zones, GKE upgrade từng zone một:

Zone A: cordon → drain → recreate → uncordon
Zone B: cordon → drain → recreate → uncordon (sau khi Zone A xong)

Thứ tự zone không được đảm bảo. Trong một zone, thứ tự node cũng không được đảm bảo.

Implication cho HA: Nếu workload chỉ có 2 replicas chạy trong cùng một zone, khi zone đó upgrade, cả 2 replicas đều có thể bị evict đồng thời. PDB minAvailable: 1 không đủ nếu cả 2 pods cùng zone. Cần kết hợp PDB với topology spread constraints.

Autopilot cluster upgrades: managed, zero-node-disruption goal

Mô hình upgrade của Autopilot

Autopilot cluster là fully managed — Google quản lý cả control plane lẫn data plane. Đối với Autopilot, upgrade mechanics khác biệt đáng kể so với Standard:

Mục tiêu thiết kế: Autopilot hướng đến zero workload disruption trong upgrade. Google đảm bảo điều này bằng cách:

Khi node cần upgrade, Autopilot không drain node ngay lập tức như Standard
Thay vào đó, Autopilot provision nodes mới với version mới trước
Workload được migrate dần sang nodes mới
Nodes cũ chỉ bị terminate khi không còn workload nào trên đó

Điều này hoạt động vì trong Autopilot, user không thấy nodes — chỉ thấy pods. Pods được reschedule sang nodes mới một cách transparent.

Extended duration pods: Autopilot có khái niệm "extended duration pods" — pods có terminationGracePeriodSeconds lớn. Autopilot có thể delay drain của node lên đến 7 ngày nếu pod có annotation này, để đảm bảo long-running workloads không bị interrupt.

Giới hạn kiểm soát trong Autopilot upgrade

Trong Autopilot, operator không thể:

Chọn upgrade strategy (surge/blue-green) — Google quyết định
Cấu hình maxSurge/maxUnavailable — không có concept này
Manually upgrade individual node pools — không có access đến node pools

Operator có thể:

Cấu hình maintenance windows để control timing
Cấu hình maintenance exclusions để block upgrade
Manual upgrade control plane (vẫn available)
Monitor upgrade progress qua Cloud Console và gcloud

bash

# Xem upgrade status Autopilot cluster
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(status,conditions)"

So sánh upgrade experience: Standard vs Autopilot

Khía cạnh	Standard	Autopilot
Kiểm soát upgrade strategy	Cao (surge/blue-green)	Không có
Node visibility	Đầy đủ	Không có
Disruption risk	Phụ thuộc vào cấu hình	Thấp (managed)
Upgrade duration	Phụ thuộc vào pool size	GKE-controlled
PDB respect	Có (tối đa 1 giờ)	Cao hơn (tối đa 7 ngày cho extended)
Zero-downtime guarantee	Phụ thuộc cấu hình đúng	Gần đạt được (best-effort)

Upgrade notifications: Pub/Sub và monitoring

Cluster notifications via Pub/Sub

GKE publish notifications về upgrade events qua Pub/Sub. Để nhận notifications:

bash

# Tạo Pub/Sub topic
gcloud pubsub topics create gke-cluster-notifications

# Enable notifications cho cluster
gcloud container clusters update CLUSTER_NAME \
    --notification-config=pubsub=ENABLED,pubsub-topic=projects/PROJECT_ID/topics/gke-cluster-notifications \
    --zone=ZONE

Các loại notification:

UpgradeEvent — khi upgrade bắt đầu hoặc hoàn thành
SecurityBulletinEvent — khi có security bulletin ảnh hưởng cluster
UpgradeAvailableEvent — khi version mới available cho channel

Notification payload format:

json

{
  "notificationConfig": {
    "pubsub": {
      "enabled": true,
      "topic": "projects/my-project/topics/gke-notifications"
    }
  },
  "payload": {
    "typeUrl": "type.googleapis.com/google.container.v1beta1.UpgradeEvent",
    "value": {
      "resourceType": "MASTER",
      "operation": "...",
      "operationStartTime": "...",
      "currentVersion": "1.28.5-gke.1091000",
      "targetVersion": "1.29.5-gke.1234567",
      "resource": "projects/.../clusters/..."
    }
  }
}

Theo dõi upgrade qua Cloud Logging

Ngoài Pub/Sub, upgrade events được log vào Cloud Logging:

bash

# Liệt kê các upgrade operations
gcloud container operations list \
    --filter="TYPE=UPGRADE_MASTER OR TYPE=UPGRADE_NODES" \
    --format="table(name,operationType,status,startTime,endTime)"

# Theo dõi trạng thái một operation cụ thể
gcloud container operations describe OPERATION_ID \
    --zone=ZONE

Metrics quan trọng để monitor trong upgrade:

kubernetes.io/container/cpu/request_utilization — sau upgrade, đảm bảo resource utilization không tăng bất thường
kubernetes.io/node/ready_node_count — theo dõi số nodes ready
Lỗi application trong khoảng thời gian upgrade

Rollout sequencing và fleet coordination

Vấn đề khi không có rollout sequencing

Trong fleet nhiều clusters, nếu tất cả clusters đều auto-upgrade tự do:

Có thể nhiều clusters upgrade đồng thời
Nếu version mới có regression, toàn bộ fleet bị impact cùng lúc
Không có canary cluster để phát hiện vấn đề trước

Cluster disruption budget trong fleet

GKE Fleet cung cấp concept cluster disruption budget để giới hạn số clusters được upgrade đồng thời trong một fleet:

Giới hạn theo percentage của fleet (ví dụ: không quá 25% clusters upgrade cùng lúc)
Hoặc theo absolute count (ví dụ: không quá 5 clusters)

Điều này tạo ra natural rollout sequencing: GKE sẽ upgrade từng batch clusters thay vì tất cả cùng lúc, cho phép team monitor health giữa các batch.

Kết hợp với staging strategy:

Release channel strategy:
- staging-cluster: Rapid channel → nhận version sớm nhất
- prod-cluster-*: Regular channel → nhận version sau staging 2 tháng
- critical-cluster-*: Stable channel → nhận version sau prod

Cluster disruption budget:
- Không quá 25% prod clusters upgrade đồng thời
- Minimum 6h giữa các batch

References

Upgrading a cluster — Commands và mechanics
Cluster upgrade concepts — High-level upgrade model
Autopilot upgrades — Managed upgrade model
Cluster notifications — Pub/Sub notification setup
Concurrent node pool upgrades — Preview feature documentation

Cơ Chế Upgrade Cluster GKE: Control Plane, Node Pool & Autopilot ​

Upgrade là quá trình có thứ tự cứng, không phải atomic operation ​

Control plane upgrade mechanics ​

Zonal cluster vs Regional cluster ​

Control plane upgrade sequence ​

Tại sao không thể skip minor version ​

Auto-upgrade vs Manual upgrade ​

Auto-upgrade: cơ chế mặc định ​

Manual upgrade ​

Verify version trước khi upgrade ​

Node pool upgrade sequencing ​

Thứ tự mặc định: sequential, một pool tại một thời điểm ​

Concurrent node pool upgrades (Preview) ​

Upgrade sequencing trong fleet nhiều clusters ​

Standard cluster upgrades: đặc điểm và control ​

Upgrade một node trong pool ​

Node upgrade trong multi-zone node pool ​

Autopilot cluster upgrades: managed, zero-node-disruption goal ​

Mô hình upgrade của Autopilot ​

Giới hạn kiểm soát trong Autopilot upgrade ​

So sánh upgrade experience: Standard vs Autopilot ​

Upgrade notifications: Pub/Sub và monitoring ​

Cluster notifications via Pub/Sub ​

Theo dõi upgrade qua Cloud Logging ​

Rollout sequencing và fleet coordination ​

Vấn đề khi không có rollout sequencing ​

Cluster disruption budget trong fleet ​

References ​

Cơ Chế Upgrade Cluster GKE: Control Plane, Node Pool & Autopilot

Upgrade là quá trình có thứ tự cứng, không phải atomic operation

Control plane upgrade mechanics

Zonal cluster vs Regional cluster

Control plane upgrade sequence

Tại sao không thể skip minor version

Auto-upgrade vs Manual upgrade

Auto-upgrade: cơ chế mặc định

Manual upgrade

Verify version trước khi upgrade

Node pool upgrade sequencing

Thứ tự mặc định: sequential, một pool tại một thời điểm

Concurrent node pool upgrades (Preview)

Upgrade sequencing trong fleet nhiều clusters

Standard cluster upgrades: đặc điểm và control

Upgrade một node trong pool

Node upgrade trong multi-zone node pool

Autopilot cluster upgrades: managed, zero-node-disruption goal

Mô hình upgrade của Autopilot

Giới hạn kiểm soát trong Autopilot upgrade

So sánh upgrade experience: Standard vs Autopilot

Upgrade notifications: Pub/Sub và monitoring

Cluster notifications via Pub/Sub

Theo dõi upgrade qua Cloud Logging

Rollout sequencing và fleet coordination

Vấn đề khi không có rollout sequencing

Cluster disruption budget trong fleet

References