Node Pool Upgrades, Draining, Maintenance Windows và Cluster Disruption Budget

Why this matters in production

Không có cluster production nào “đứng yên”: kernel patches, Kubernetes versions, node image CVE fixes, thay đổi machine type. Mọi thay đổi đó cuối cùng đều đi qua node replacement. Nếu chiến lược nâng cấp không khớp với kiến trúc workload, bạn sẽ tự tạo outage dù control plane vẫn khỏe.

GKE hỗ trợ nhiều chiến lược nâng cấp node pool, tiêu biểu là surge upgrade và blue-green upgrade (Node upgrade strategies). Việc chọn strategy thực chất là bài toán đánh đổi giữa tốc độ, chi phí tạm thời, và mức an toàn rollback.

Internal model

Surge upgrade hoạt động như thế nào

Surge upgrade tạo thêm node tạm (maxSurge), drain node cũ, di chuyển pod, rồi xóa node cũ. Mức song song phụ thuộc maxSurge và maxUnavailable (Configure node upgrade strategy).

Mental model:

1. Thêm công suất tạm thời.
2. Rút pod khỏi node cũ có kiểm soát.
3. Đưa workload lên node mới.
4. Thu hồi node cũ.

Nếu quota hoặc capacity zone không đủ cho node surge, tiến trình có thể chậm hoặc kẹt. Vì vậy surge không chỉ là “tham số Kubernetes”, mà còn là bài toán Compute Engine quota/capacity.

Blue-green upgrade hoạt động như thế nào

Blue-green tạo song song “green pool” bên cạnh “blue pool”. Workload được chuyển theo lô/batch, có thể có soak period quan sát trước khi xóa blue pool (Node upgrade strategies).

Ưu điểm lớn nhất: rollback nhanh hơn vì blue pool còn nguyên trong giai đoạn chuyển tiếp. Nhược điểm: đòi thêm tài nguyên tạm nhiều hơn surge.

Cordon vs drain: khác biệt vận hành

• Cordon: đánh dấu node không nhận pod mới (unschedulable), pod đang chạy vẫn ở lại.
• Drain: evict pod có kiểm soát (tôn trọng PDB) để rỗng node và thực hiện bảo trì.

Đây là ranh giới quan trọng giữa “ngừng nhận tải mới” và “thực sự di dời workload”. Nhiều sự cố xuất phát từ việc cordon xong tưởng đã an toàn, nhưng pod cũ vẫn bám node lỗi.

PodDisruptionBudget và stuck drain

Kubernetes PDB giới hạn số pod bị gián đoạn đồng thời do voluntary disruptions (PodDisruptionBudget). Trong nâng cấp node:

• PDB quá chặt (maxUnavailable: 0 với replica thấp) dễ gây drain kẹt.
• Drain kẹt kéo dài có thể đẩy toàn bộ upgrade ra ngoài maintenance window.

Anti-pattern rất phổ biến: dùng PDB để “khóa mọi thay đổi” thay vì bảo vệ SLO theo tỷ lệ lỗi chấp nhận được.

Maintenance windows và exclusions

GKE cho phép định nghĩa maintenance windows (thời điểm cho phép) và exclusions (thời điểm cấm) cho hoạt động bảo trì tự động, bao gồm auto-upgrade (Maintenance windows and exclusions).

Điểm cần nhớ trong production:

• Window chỉ kiểm soát khi nào thay đổi được phép chạy.
• Nó không thay thế readiness của workload.
• Một số hoạt động hạ tầng phụ thuộc bên dưới vẫn có thể diễn ra ngoài khung mong muốn, vì vậy bạn luôn cần thiết kế ứng dụng resilient.

Cluster Disruption Budget (CDB) và fleet operations

Trong GKE, Cluster Disruption Budget kiểm soát tần suất gián đoạn do auto-upgrade ở cấp cluster theo chu kỳ (ví dụ patch/minor cadence) (Cluster disruption budget).

PDB và CDB giải hai bài toán khác nhau:

• PDB: giới hạn gián đoạn đồng thời ở workload.
• CDB: giới hạn tần suất gián đoạn theo thời gian ở cluster.

Trong môi trường nhiều cluster (fleet), CDB giúp tránh trường hợp nhiều cluster cùng upgrade sát nhau làm đội vận hành quá tải hoặc vượt error budget toàn nền tảng.

Production architecture patterns

Pattern 1: Workload tiering + upgrade strategy theo tier

• Tier 0 (critical API): blue-green + soak.
• Tier 1 (business services): surge với maxSurge vừa phải.
• Tier 2 (batch/analytics): surge nhanh, chấp nhận maxUnavailable cao hơn.

Không có một strategy duy nhất tốt cho tất cả. Strategy phải đi theo business criticality.

Pattern 2: Progressive upgrade theo cluster rings

Chia môi trường theo vòng:

1. Ring 0: staging/canary cluster.
2. Ring 1: low-risk production cluster.
3. Ring 2: core production cluster.

Mỗi ring chạy sau ring trước một khoảng thời gian đủ để quan sát lỗi latent. Đây là nguyên tắc Reliability cổ điển: hạn chế blast radius theo từng đợt (Reliability pillar).

Pattern 3: Pre-upgrade capacity check bắt buộc

Trước upgrade, kiểm tra:

• Quota CPU/VM ở từng zone.
• Khả năng scale của backend phụ thuộc khi pod migrate.
• Sức chịu tải của DNS/service mesh khi pod churn tăng.

Không làm bước này, surge/blue-green có thể fail vì lý do hạ tầng chứ không phải Kubernetes logic.

Real-world scenarios

Scenario A: Surge upgrade làm tăng latency đột ngột

Nguyên nhân:

• maxSurge quá cao, quá nhiều pod restart đồng thời.
• Cache nóng bị mất đồng loạt, backend DB tăng tải.

Khắc phục:

• Giảm concurrency nâng cấp.
• Bổ sung warm-up probe trước khi nhận traffic.
• Dùng topology spread để tránh mất pod cùng AZ cùng lúc.

Scenario B: Blue-green thành công kỹ thuật nhưng fail business

Nguyên nhân:

• Green pool chạy ổn ở metrics hệ thống, nhưng hiệu năng ứng dụng giảm do thay đổi CPU micro-architecture.
• Soak period quá ngắn, lỗi chỉ lộ sau 2–3 giờ tải thật.

Khắc phục:

• Kéo dài soak theo chu kỳ traffic thật.
• So sánh p95/p99 theo business transaction, không chỉ CPU/memory.

Scenario C: Maintenance exclusion bị hiểu sai

Nguyên nhân:

• Đội vận hành nghĩ exclusion là “đóng băng mọi thay đổi”.
• Nhưng workload vẫn chưa có pod spread tốt, một sự cố node đơn lẻ vẫn làm mất quorum.

Khắc phục:

• Exclusion chỉ là lớp giảm thay đổi có chủ đích; vẫn phải đảm bảo kiến trúc chịu lỗi ở application layer.

Common mistakes / anti-patterns

1. Đặt maxUnavailable cao để upgrade nhanh rồi hy vọng PDB cứu

   • Vì sao xảy ra: áp lực deadline vá bảo mật.
   • Hệ quả: pod quan trọng bị dồn dập restart, latency spike.
   • Phòng tránh: cân bằng tham số theo SLO và replica thực tế.

2. Không dự phòng quota cho surge/blue-green

   • Vì sao xảy ra: tính toán capacity chỉ theo steady-state.
   • Hệ quả: upgrade treo giữa chừng, cluster ở trạng thái nửa cũ nửa mới kéo dài.
   • Phòng tránh: dành buffer capacity theo peak upgrade plan.

3. Coi PDB như cơ chế ngăn mọi evict

   • Vì sao xảy ra: nhầm PDB là “bảo hiểm tuyệt đối”.
   • Hệ quả: drain timeout, force actions, rủi ro dữ liệu.
   • Phòng tránh: đặt PDB theo mức gián đoạn chấp nhận được và replica tối thiểu.

4. Không thử runbook stuck drain trước ngày nâng cấp lớn

   • Vì sao xảy ra: thiếu diễn tập.
   • Hệ quả: sự cố kéo dài vì không rõ thứ tự xử lý.
   • Phòng tránh: tabletop + game day cho các tình huống drain không kết thúc.

GCP-native implementation guidance

Cấu hình surge upgrade

gcloud container node-pools update <node-pool> \
  --cluster=<cluster-name> \
  --region=<region> \
  --max-surge-upgrade=1 \
  --max-unavailable-upgrade=0

Cấu hình blue-green upgrade

gcloud container node-pools update <node-pool> \
  --cluster=<cluster-name> \
  --region=<region> \
  --enable-blue-green-upgrade

Cấu hình maintenance window

gcloud container clusters update <cluster-name> \
  --region=<region> \
  --maintenance-window-start=2025-06-01T02:00:00Z \
  --maintenance-window-end=2025-06-01T06:00:00Z \
  --maintenance-window-recurrence='FREQ=WEEKLY;BYDAY=SA,SU'

Kiểm tra node drain blockers

kubectl get pdb -A
kubectl describe pdb -A
kubectl get pods -A --field-selector spec.nodeName=<node-name>

Thiết kế quyết định: surge hay blue-green?

Tiêu chí	Surge	Blue-green
Tốc độ rollout	Nhanh với pool vừa/nhỏ	Có thể chậm hơn do soak
Tài nguyên tạm thời	Trung bình	Cao
Rollback	Không tức thời	Tốt hơn trong giai đoạn song song
Phù hợp workload	Stateless phổ thông	Dịch vụ critical, yêu cầu an toàn cao

Kết nối Architecture Framework

• Reliability: giới hạn gián đoạn có chủ đích bằng strategy phù hợp + PDB + CDB (Reliability).
• Operational Excellence: chuẩn hóa quy trình nâng cấp thành pipeline có pre-check và rollback rõ ràng (Operational excellence).

References

• Node upgrade strategies
• Configure node upgrade strategies
• Ensure resources for node upgrades
• Maintenance windows and exclusions
• Configure maintenance windows and exclusions
• Cluster disruption budget
• PodDisruptionBudget
• Google Cloud Architecture Framework

Phụ lục chuyên sâu: kiến trúc nâng cấp không phá vỡ SLO

Mô hình quyết định nhiều tầng cho upgrade windows

Một kế hoạch nâng cấp production tốt nên có ba tầng:

1. Tầng lịch (calendar layer)

   • Khi nào được phép thay đổi (maintenance window).
   • Khi nào cấm thay đổi (exclusion theo sự kiện kinh doanh).

2. Tầng kỹ thuật (execution layer)

   • Surge hay blue-green.
   • Batch size, soak time, rollback point.

3. Tầng business (risk layer)

   • Mức lỗi tối đa chấp nhận trong mỗi đợt.
   • Tiêu chí dừng rollout ngay lập tức.

Sai lầm phổ biến là chỉ làm tầng lịch mà thiếu hai tầng còn lại.

Surge tuning theo loại workload

Workload API latency-sensitive

• maxSurge thấp để giảm đồng thời restart.
• maxUnavailable=0 hoặc rất thấp.
• Ưu tiên readiness chặt và warmup trước nhận traffic.

Workload background workers

• Có thể tăng maxSurge và maxUnavailable để rút ngắn thời gian upgrade.
• Chấp nhận throughput giảm tạm thời nếu queue có buffering tốt.

Workload stateful có replication

• Cần kết hợp chặt giữa PDB, anti-affinity và thứ tự rollout.
• Không được để nhiều replica cùng shard rơi vào cùng một đợt drain.

Blue-green: khi nào đáng chi thêm tài nguyên

Blue-green phù hợp khi:

• Mỗi phút downtime mang chi phí cao.
• Cần rollback cực nhanh trong cùng phiên thay đổi.
• Workload nhạy với thay đổi kernel/image/runtime.

Không nên mặc định blue-green cho mọi pool vì chi phí tài nguyên và độ phức tạp điều phối cao hơn.

Stuck drain xử lý theo thứ tự ưu tiên

1. Xác định pod nào đang chặn drain.
2. Kiểm tra PDB liên quan.
3. Xác định pod có preStop quá dài hoặc termination không kết thúc.
4. Đánh giá có thể tạm nới PDB không.
5. Chỉ cưỡng bức khi đã hiểu rõ hậu quả nghiệp vụ.

Nguyên tắc: cưỡng bức eviction là biện pháp cuối, không phải mặc định.

Kết hợp CDB và PDB trong tổ chức nhiều đội

Trong tổ chức lớn, nhiều đội cùng chạy trên một cluster hoặc nhiều cluster. Nên chuẩn hóa:

• Mẫu PDB theo từng tier dịch vụ.
• CDB theo môi trường (prod-core, prod-edge, staging).
• Cơ chế phê duyệt thay đổi policy trước mùa cao điểm.

Mục tiêu là tránh tình huống mỗi đội “tối ưu riêng” làm hệ thống tổng thể khó nâng cấp.

Quan sát quality của một đợt nâng cấp

Đừng chỉ đánh dấu “upgrade succeeded”. Hãy đo:

• Tỷ lệ pod restart không mong muốn.
• Thời gian drain trung vị/p95.
• Lượng request lỗi trong và sau mỗi batch.
• Thời gian phục hồi về baseline latency.

Nếu các chỉ số này xấu lên theo từng đợt nhưng rollout vẫn “xanh”, đó là nợ vận hành tích lũy.

Thiết kế rollback trước khi nhấn upgrade

Checklist rollback tối thiểu:

• Có node pool cũ còn nguyên hay không?
• Có giới hạn traffic shift để quay đầu nhanh không?
• Có runbook rõ ai quyết định rollback và trong bao lâu?
• Có tiêu chí định lượng để kích hoạt rollback không?

Không có rollback plan nghĩa là đang đánh cược SLO vào may mắn.

Anti-pattern theo chu kỳ phát hành

Chu kỳ quá dày nhưng không có guardrail

• Đội nền tảng chạy nâng cấp liên tục.
• Đội ứng dụng liên tục deploy lớn.
• Hai nhịp đổi chồng lên nhau tạo vùng nhiễu khó debug.

Giải pháp:

• Chốt “change budget” theo tuần.
• Tránh chồng đợt nâng cấp node với migration schema lớn.

Kiến trúc đa cluster và fleet scenarios

Khi có nhiều cluster production theo vùng/quốc gia:

• Không nâng cấp đồng thời tất cả cluster cùng vai trò business.
• Duy trì ít nhất một cluster “ổn định” làm fallback traffic.
• Dùng CDB để kiểm soát tần suất disruption ở từng cluster.

Điểm này bám sát nguyên tắc giảm blast radius của Reliability pillar.

Mối quan hệ giữa maintenance windows và capacity planning

Window bảo trì vào giờ thấp điểm là tốt, nhưng nếu giờ thấp điểm cũng là thời gian backup/batch chạy lớn thì drain vẫn đau như thường. Vì vậy chọn window cần dựa trên profile tài nguyên thực tế, không chỉ dựa trên lượng người dùng online.

Khuyến nghị tổ chức quy trình nâng cấp

• Một owner kỹ thuật chịu trách nhiệm cấu hình upgrade strategy.
• Một owner vận hành chịu trách nhiệm readiness/rollback.
• Một owner sản phẩm chịu trách nhiệm risk acceptance khi cần thay đổi gần ngày cao điểm.

Sự rõ vai trò giúp quyết định nhanh khi incident xảy ra giữa rollout.

Dashboard tối thiểu cho nâng cấp node pools

Bảng theo dõi nên có:

• Tiến độ node upgraded / total nodes.
• Số pod bị evict theo namespace.
• Tỷ lệ lỗi HTTP/gRPC theo service tier.
• Latency p95/p99 trước-trong-sau rollout.
• Số lần rollback hoặc pause rollout.

Bài học thực chiến

• Upgrade nhanh không có nghĩa là tốt nếu tạo ra “degraded mode” kéo dài.
• Đôi khi rollout chậm hơn 30% nhưng an toàn hơn cho error budget là lựa chọn đúng.
• Tối ưu kỹ thuật phải phục vụ ưu tiên business, không phải ngược lại.

References bổ sung

• Upgrading clusters and node pools
• Release channels
• Operational excellence in cloud operations

FAQ thực chiến

Bao lâu nên nâng cấp node pool một lần?

Không có lịch cố định cho mọi tổ chức. Lịch nâng cấp nên cân bằng ba yếu tố: rủi ro bảo mật nếu chậm vá, khả năng hấp thụ thay đổi của đội vận hành, và chu kỳ kinh doanh. Quan trọng nhất là lịch phải ổn định và dự đoán được.

Nếu PDB quá chặt thì có nên bỏ PDB để upgrade nhanh?

Không nên bỏ hoàn toàn. Cách đúng là điều chỉnh PDB theo tier dịch vụ và tăng replica hợp lý trước nâng cấp. Bỏ PDB thường khiến lỗi chuyển từ “nâng cấp chậm” sang “mất availability”.

Blue-green có luôn tốt hơn surge không?

Không. Blue-green an toàn hơn trong một số trường hợp nhưng tốn tài nguyên và vận hành phức tạp hơn. Với nhiều workload stateless phổ thông, surge tuning tốt là đủ.

Maintenance window có thay thế được kiến trúc chịu lỗi không?

Không. Window chỉ hạn chế thời điểm thay đổi chủ động, không loại bỏ được sự cố bất ngờ. Ứng dụng vẫn phải chịu lỗi tốt ở mọi thời điểm.

Checklist vận hành chi tiết trước - trong - sau nâng cấp

Trước nâng cấp

• Xác nhận quota đủ cho surge/blue-green theo từng zone.
• Xác nhận node pool autoscaling không bị giới hạn sai.
• Rà soát PDB của toàn bộ namespace quan trọng.
• Kiểm tra các workload có terminationGracePeriodSeconds quá dài.
• Kiểm tra backlog của hàng đợi để tránh nâng cấp lúc queue đang đỉnh.
• Khóa các thay đổi ứng dụng rủi ro cao trong khung nâng cấp.

Trong nâng cấp

• Theo dõi tốc độ drain trung vị/p95 theo batch.
• Theo dõi error rate theo service tier, không chỉ toàn cục.
• Theo dõi mức tăng restart count bất thường.
• Theo dõi saturation ở DB/cache/message broker do pod warmup.
• Pause rollout ngay khi vượt ngưỡng error budget đã định.

Sau nâng cấp

• Xác nhận không còn pod bị kẹt scheduling.
• So sánh latency p95/p99 trước và sau 24 giờ.
• So sánh tỷ lệ lỗi tại giờ cao điểm đầu tiên sau nâng cấp.
• Cập nhật nhật ký thay đổi, bài học và điều chỉnh policy nếu cần.

Bài học tổ chức

Đợt nâng cấp thành công không nên kết thúc ở trạng thái “đã xong”. Giá trị thật nằm ở vòng phản hồi: đợt sau phải an toàn hơn đợt trước. Nếu không có vòng phản hồi, tổ chức sẽ lặp lại lỗi cũ dưới hình thức mới.

Phụ lục tình huống nâng cấp theo ngành

Fintech

Đặc thù:

• Thời điểm giao dịch cao điểm rõ ràng.
• Yêu cầu audit thay đổi nghiêm ngặt.

Khuyến nghị:

• Dùng blue-green cho pool xử lý giao dịch trực tiếp.
• Soak kéo dài qua ít nhất một chu kỳ giao dịch lớn.
• Có exclusion cho ngày chốt sổ/kỳ thanh toán.

SaaS B2B

Đặc thù:

• Nhiều tenant với mức quan trọng khác nhau.
• Khả năng degraded có thể chấp nhận theo tenant class.

Khuyến nghị:

• Pool critical riêng cho tenant enterprise.
• Surge nhanh hơn cho pool tenant tiêu chuẩn.
• Đo disruption theo tenant SLO thay vì chỉ nhìn toàn cục.

Nền tảng dữ liệu nội bộ

Đặc thù:

• Batch workloads lớn, thời gian chạy dài.
• Có thể chịu gián đoạn có kiểm soát.

Khuyến nghị:

• Dùng surge với maxUnavailable cao hơn.
• Chọn window tránh giờ ETL trọng yếu.
• Tối ưu rollback ở mức pipeline, không nhất thiết rollback node pool ngay.