Chương 15: GKE Upgrade Mechanics & Disruption Management
Tại sao chương này quan trọng
Upgrade sai chiến lược là một trong những nguyên nhân hàng đầu gây ra production outage trong môi trường Kubernetes. Không giống như các failure mode thông thường (application crash, OOM, network partition), upgrade-induced disruption thường xảy ra có kế hoạch — nhưng lại được thực hiện thiếu chuẩn bị.
Trên GKE, mọi cluster đều sẽ được upgrade — không phải "nếu" mà là "khi nào". Control plane được Google quản lý và tự động upgrade theo release channel. Node pools, nếu bật auto-upgrade, sẽ được rolling-update theo lịch được xác định bởi maintenance window. Workload nào không được thiết kế đúng cho disruption tolerance sẽ bị impact khi drain và recreate node diễn ra.
Chương này đi sâu vào toàn bộ upgrade mechanics của GKE từ góc độ production engineering: release channel model và cách GKE quản lý version cadence, cơ chế upgrade cụ thể ở cấp độ control plane và node pool, chiến lược surge vs blue-green với trade-off thực tế, cách sử dụng maintenance windows và exclusion để kiểm soát timing, và cuối cùng là cách chuẩn bị workload và troubleshoot khi upgrade gặp vấn đề.
Điều kiện tiên quyết
- Chương 5: GKE control plane internals — hiểu cách control plane hoạt động, release channel model cơ bản
- Chương 6: Node lifecycle — node bootstrap, auto-repair, drain mechanics
- Chương 7: GKE networking — packet path, VPC-native
- Chương 13: Workload Identity — liên quan đến credential rotation trong upgrade
Cấu trúc chương
| Bài | Chủ đề | Mức độ quan trọng |
|---|---|---|
| 01. Release Channels & Versioning | Rapid/Regular/Stable/Extended cadence, version skew policy, n-2 support | ⭐⭐⭐⭐⭐ |
| 02. Cluster Upgrade Mechanics | Control plane upgrade, node pool sequencing, Standard vs Autopilot, auto vs manual | ⭐⭐⭐⭐⭐ |
| 03. Node Upgrade Strategies | Surge vs blue-green — mechanics, trade-offs, khi nào dùng cái nào | ⭐⭐⭐⭐⭐ |
| 04. Maintenance Windows & Exclusions | Scheduling, UTC timezone, blackout periods, disruption budget, rollout sequencing | ⭐⭐⭐⭐⭐ |
| 05. Workload Disruption Readiness | PodDisruptionBudget, pod-deletion-cost, safe-to-evict, upgrade notifications | ⭐⭐⭐⭐⭐ |
| 06. Troubleshooting & Testing Upgrades | Stuck upgrades, manual intervention, staging cluster validation, kubectl drain testing | ⭐⭐⭐⭐⭐ |
Mental model cốt lõi
Để làm chủ GKE upgrades, cần nắm ba lớp control plane:
┌─────────────────────────────────────────────────────────────┐
│ LAYER 1: VERSION POLICY (Google quyết định) │
│ Release channel → version cadence → auto-upgrade target │
├─────────────────────────────────────────────────────────────┤
│ LAYER 2: TIMING CONTROL (Operator quyết định) │
│ Maintenance windows + Exclusions + Disruption Budget │
├─────────────────────────────────────────────────────────────┤
│ LAYER 3: DISRUPTION CONTROL (Developer quyết định) │
│ PodDisruptionBudget + Termination grace + Replica count │
└─────────────────────────────────────────────────────────────┘Mỗi layer có failure mode riêng. Outage xảy ra khi layer 2 và layer 3 không được cấu hình đúng cho upgrade event mà layer 1 kích hoạt.
Bản đồ quyết định upgrade strategy
Workload có PDB restrictive (maxUnavailable=0)?
├── Có: Blue-green upgrade (soak validation + rollback)
│ └── Stateful workload với PVC? → Cần test volume reattach
└── Không: Surge upgrade (nhanh hơn, ít resource hơn)
├── maxSurge=1, maxUnavailable=0 (mặc định, an toàn)
└── maxSurge=3, maxUnavailable=3 (nhanh hơn, rủi ro hơn)