Chapter 62: GKE Cluster Upgrade Runbook — Quy Trình Zero-Downtime
Tại sao chương này quan trọng trong production
Nâng cấp cluster không phải là một sự kiện tùy chọn trên GKE — nó là một chu trình bắt buộc, lặp lại vĩnh viễn. Google Cloud giới hạn số lượng minor version mà một control plane được hỗ trợ đồng thời, và khi một minor version hết hỗ trợ, GKE buộc nâng cấp cluster của bạn cho dù bạn có muốn hay không:
Theo tài liệu chính thức, "Regardless of your cluster's settings, GKE performs automatic upgrades at the end of support" — tức là dù bạn tắt hết auto-upgrade, đặt maintenance exclusion dài nhất có thể, GKE vẫn sẽ ép nâng cấp khi minor version của bạn chạm mốc end-of-support (xem Standard cluster upgrades).
Điều này biến "cluster upgrade" từ một tác vụ vận hành ngẫu nhiên thành một quy trình chu kỳ mà mọi platform team phải làm chủ, giống như patching OS hay rotate secrets. Vấn đề là: một node pool upgrade thực chất là một cuộc "di cư" toàn bộ workload từ tập node cũ sang tập node mới — mọi Pod đang chạy đều bị cordon, drain, và reschedule. Nếu không hiểu đúng cơ chế bên trong (surge sizing, PDB, soak time, health check gate), một upgrade tưởng chừng "click một nút" có thể gây:
- Outage do PDB quá chặt khiến GKE buộc phải force-delete Pod sau 60 phút chờ.
- Cascading failure do surge node không đủ capacity, làm cluster autoscaler và surge upgrade tranh giành quota cùng lúc.
- Version skew vi phạm (node pool bị bỏ quên quá 2 minor version so với control plane), dẫn tới API server từ chối giao tiếp với kubelet.
- Rollback thất bại giữa chừng vì hiểu nhầm rằng control plane có thể "hạ minor version" như node pool.
Chương này xây dựng runbook đầy đủ, đi từ cơ chế nội tại của từng giai đoạn upgrade đến các quyết định vận hành thực tế cần đưa ra trước, trong, và sau khi nâng cấp.
Mental model tổng quát: Upgrade là hai state machine độc lập nhưng ràng buộc lẫn nhau
Điều quan trọng nhất cần nắm trước khi đọc các subtopic: control plane và node pool là hai đối tượng nâng cấp hoàn toàn tách biệt, mỗi bên có state machine, cơ chế rollout, và giới hạn rollback riêng — nhưng bị ràng buộc bởi version skew policy. Bạn không "nâng cấp cluster" như một hành động nguyên tử; bạn nâng cấp control plane trước, sau đó nâng cấp từng node pool, và trong suốt quá trình đó hai phía chạy hai phiên bản Kubernetes khác nhau một cách hợp lệ và có chủ đích.
Theo tài liệu chính thức: "A cluster's control plane and nodes don't necessarily run the same version at all times, however they must adhere to the GKE version skew policy."
Đây là lý do runbook này được chia thành 7 giai đoạn tuần tự, mỗi giai đoạn là một file riêng — chúng phản ánh đúng trình tự vận hành thật, không phải một cách phân loại tùy ý:
- Pre-upgrade validation — kiểm tra compatibility trước khi động vào bất cứ thứ gì.
- Node surge strategy — quyết định cơ chế rollout cho node pool.
- PDB configuration — đảm bảo workload có "ngân sách" chịu disruption.
- Control plane upgrade window — nâng cấp control plane, giám sát, biết khi nào phải dừng.
- Node pool upgrade execution — thực thi và giám sát rollout node.
- Post-upgrade validation — xác nhận hệ thống thực sự khỏe sau upgrade.
- Rollback procedures — quy trình khẩn cấp khi mọi thứ đi sai hướng.
Phạm vi và đối tượng đọc
Chương này giả định bạn đã đọc Chapter 15 — GKE Upgrade Mechanics (cơ chế release channel, version skew, auto-upgrade) và Chapter 54 — Incident Response & Postmortems (kỷ luật vận hành khi có sự cố). Chương 15 giải thích tại sao GKE thiết kế upgrade như vậy; chương này tập trung vào quy trình thực thi từng bước khi bạn là người trực tiếp cầm runbook trong tay lúc nâng cấp một cluster production.
Runbook này áp dụng cho GKE Standard. Autopilot có cơ chế tương tự nhưng loại bỏ phần lớn quyết định thủ công về surge/blue-green (Google tự chọn tham số), nên các phần liên quan đến tinh chỉnh maxSurge/batch size sẽ được ghi rõ là "chỉ áp dụng cho Standard" khi cần.
Cách dùng runbook này
Mỗi file trong chương đi theo đúng trình tự thực thi thời gian thực của một lần upgrade — đọc tuần tự từ 01 đến 07 nếu bạn đang chuẩn bị cho một cửa sổ nâng cấp thật. Nếu bạn đang ở giữa một sự cố upgrade đang diễn ra, nhảy thẳng tới 04, 05, hoặc 07 tùy giai đoạn bạn đang mắc kẹt.
Mỗi subtopic được viết theo nguyên tắc: cơ chế trước, checklist sau. Bạn cần hiểu vì sao GKE hành xử như vậy trước khi làm theo bất kỳ danh sách lệnh gcloud nào — vì trong một sự cố thật, checklist chỉ hữu ích khi bạn hiểu đủ để biết lúc nào cần lệch khỏi nó.