My Awesome Project

Appearance

Chương 6: GKE Node Lifecycle & Quản Trị Node Pool ​

Vì sao chương này quyết định độ ổn định production ​

Trong phần lớn sự cố vận hành GKE, triệu chứng ban đầu hiếm khi đến từ control plane; nó bắt đầu từ node: NotReady, DiskPressure, eviction dây chuyền, pod bị kill khi nâng cấp, hoặc capacity không đủ khi autoscaler mở rộng. Nếu Chapter 5 giúp bạn hiểu “bộ não” của cluster, thì Chapter 6 là phần giúp bạn làm chủ “hệ thần kinh ngoại biên” — nơi workload thực sự chạy.

Google Cloud định nghĩa rõ node pool là đơn vị vận hành chính trong Standard clusters, bao gồm cấu hình máy, image, cơ chế nâng cấp, auto-repair, autoscaling và nhiều policy liên quan (Node pools). Đồng thời, Kubernetes quy định node health qua Node conditions và hành vi eviction ở kubelet (Node conditions, Node-pressure eviction). Hai lớp này giao nhau tại production theo cách rất “thực chiến”: một ngưỡng eviction đặt sai có thể kích hoạt auto-repair hàng loạt; một chiến lược upgrade chọn sai có thể phá vỡ SLO dù PDB đã cấu hình.

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

  • Đã hoàn thành Chương 5 về GKE Control Plane Internals.
  • Nắm Linux/Kubernetes cơ bản: cgroups, container runtime, kubelet, taints/tolerations.
  • Có kinh nghiệm vận hành workload stateful/stateless trên GKE.

Mức độ sâu ​

5/5 — Nội dung tập trung vào quyết định kiến trúc và vận hành ở quy mô production, có đối chiếu trực tiếp với tài liệu chính thức của GKE, Kubernetes và Compute Engine.

Cấu trúc chapter ​

1. COS, Node Bootstrap, Node Conditions & Auto-Repair ​

Tập trung vào nền tảng runtime của node:

  • Container-Optimized OS (COS): kernel hardening, root filesystem immutable, update model
  • Trình tự bootstrap node: đăng ký kubelet, startup taints, chuyển trạng thái Ready
  • Node conditions: Ready, DiskPressure, MemoryPressure, PIDPressure, NetworkUnavailable
  • Cơ chế phát hiện điều kiện lỗi và eviction
  • Cơ chế Node Auto-Repair của GKE: trigger, drain timeout, retry logic

2. Node Pool Upgrades, Draining, Maintenance Windows & Cluster Disruption Budget ​

Tập trung vào thay đổi có kiểm soát:

  • Surge upgrade: maxSurge, maxUnavailable, trình tự thay node
  • Blue-green upgrade: pool song song, soak phase, cutover
  • Cordoning vs draining và tương tác với PodDisruptionBudget
  • Maintenance windows/exclusions và tác động tới auto-upgrade
  • Cluster disruption budget để khống chế tần suất gián đoạn từ auto-upgrade

3. Spot, ARM, Confidential Nodes, Reservations & Node Labeling ​

Tập trung vào lựa chọn hạ tầng và ràng buộc vận hành:

  • Spot VMs trong GKE: preemption và shutdown warning
  • Node termination grace period và chiến lược shutdown an toàn
  • ARM-based nodes (Tau T2A): tương thích workload và scheduling
  • Confidential Nodes (AMD SEV/SEV-SNP): bảo mật in-use và chi phí hiệu năng
  • Reservations (zonal/regional) và đảm bảo capacity
  • Node labeling strategy cho routing workload chuẩn production

4. Max Pods, Flex Pod CIDR, Boot Disk, Local SSD & Capacity Design ​

Tập trung vào giới hạn tài nguyên node theo networking/storage:

  • maxPodsPerNode và bài toán cạn IP alias range
  • Flexible/discontiguous Pod CIDR để mở rộng cluster
  • Thiết kế boot disk: size, IOPS/throughput, rủi ro image pull
  • Local SSD: tính ephemeral, mẫu workload phù hợp, anti-pattern phổ biến
  • Snapshot/backup và tác động đến RTO/RPO

5. kubelet & containerd Configuration cho Production GKE ​

Tập trung vào lớp cấu hình runtime sâu:

  • Node system configuration và kubelet knobs quan trọng
  • Ngưỡng eviction, image garbage collection, CPU manager, PID limits
  • Lộ trình cgroup v2 và rủi ro tương thích runtime/application
  • Containerd cấu hình registry mirror, custom TLS CA, image pulling
  • Chuẩn hóa policy để tránh drift giữa các node pools

Cách đọc chapter theo mục tiêu công việc ​

Nếu bạn đang giảm sự cố node hàng ngày ​

  1. Bắt đầu từ file 1 (bootstrap/conditions/auto-repair).
  2. Đọc ngay file 2 (drain/maintenance/disruption control).
  3. Quay lại file 5 để chuẩn hóa kubelet/containerd.

Nếu bạn đang thiết kế cluster mới cho production ​

  1. File 4 (IP, disk, storage) để khóa capacity model từ đầu.
  2. File 3 (Spot/ARM/Confidential/Reservation) để chọn profile hạ tầng.
  3. File 2 để chọn chiến lược nâng cấp theo SLO.

Nếu bạn đang migrate cluster hiện hữu ​

  1. File 5 (config runtime và cgroup v2).
  2. File 2 (blue-green/surge và cửa sổ bảo trì).
  3. File 1 để thiết kế guardrail auto-repair và observability.

Khung quyết định production (tóm tắt) ​

Quyết địnhTác động chínhRủi ro nếu làm saiFile nên đọc
Chọn strategy upgradeAvailability trong release cyclePod bị evict vượt ngưỡng, rollout kéo dài2
Chọn max pods/nodeMật độ pod và cạn IP rangePending pod do thiếu IP dù còn CPU/RAM4
Bật Spot cho workload nàoChi phí computeSLO giảm do preemption burst3
Chuyển cgroup v2 khi nàoỔn định runtime dài hạnLỗi tương thích app/agent nền5
Ngưỡng eviction kubeletKhả năng tự bảo vệ nodeThrashing, auto-repair dây chuyền1, 5

Cross-reference với Google Cloud Architecture Framework / Well-Architected ​

  • Reliability: khuyến nghị thiết kế chống lỗi, failover có kiểm soát, và giới hạn blast radius (Reliability pillar).
  • Operational Excellence: tự động hóa thao tác vận hành lặp lại, chuẩn hóa policy, và giảm toil qua guardrails (Operational excellence pillar).

Trong chapter này, mọi pattern đều được viết theo hai trục đó: giữ dịch vụ hoạt động ổn định khi có thay đổi node, và giảm lỗi do thao tác thủ công trong lifecycle dài hạn.

References chung của chapter ​

Production roadmap đề xuất cho Chapter 6 ​

Giai đoạn 1: Ổn định nền tảng node lifecycle (2–4 tuần triển khai thực tế) ​

Mục tiêu chính:

  • Loại bỏ các sự cố node lặp lại dễ dự đoán (disk pressure, memory pressure, stuck drain).
  • Chuẩn hóa cách quan sát node health theo node pool.
  • Đưa auto-repair và upgrade từ trạng thái “bật mặc định” sang trạng thái “được kiểm soát”.

Deliverables nên có:

  • Dashboard node conditions theo từng pool và từng zone.
  • Runbook chuẩn cho NotReady, DiskPressure, MemoryPressure.
  • Checklist pre-upgrade bắt buộc chạy trước mọi đợt nâng cấp.

Giai đoạn 2: Nâng độ an toàn thay đổi (4–8 tuần) ​

Mục tiêu chính:

  • Tách rõ workload tiers và map với chiến lược upgrade tương ứng.
  • Cấu hình maintenance windows/exclusions bám lịch kinh doanh.
  • Đặt CDB/PDB hợp lý để không kẹt drain nhưng vẫn bảo vệ availability.

Deliverables nên có:

  • Tài liệu policy surge/blue-green theo từng loại dịch vụ.
  • Mẫu PDB chuẩn cho các tier phổ biến.
  • Pipeline nâng cấp theo rings (staging → prod low-risk → prod core).

Giai đoạn 3: Tối ưu cost-security-performance ở lớp node options (8–12 tuần) ​

Mục tiêu chính:

  • Sử dụng Spot có kiểm soát và có floor capacity on-demand/reserved.
  • Đánh giá ARM pools cho nhóm workload phù hợp.
  • Áp dụng Confidential Nodes cho dữ liệu nhạy cảm theo phân loại.

Deliverables nên có:

  • Bảng phân loại workload theo profile node đề xuất.
  • Báo cáo benchmark ARM vs x86 theo chỉ số nghiệp vụ.
  • Chính sách labeling/scheduling nhất quán toàn nền tảng.

Giai đoạn 4: Chuẩn hóa runtime governance (liên tục) ​

Mục tiêu chính:

  • Quản lý kubelet/containerd config theo “policy as code”.
  • Giảm drift giữa clusters.
  • Làm chủ migration cgroup v2 và trust chain registry.

Deliverables nên có:

  • Baseline config theo môi trường và theo pool class.
  • Quy trình thay đổi runtime có canary + rollback.
  • Bộ KPI runtime health dùng chung.

Mô hình tổ chức trách nhiệm (RACI gợi ý) ​

Platform team ​

Chịu trách nhiệm:

  • Kiến trúc node pools và policy nâng cấp.
  • Cấu hình maintenance windows/CDB ở mức cluster.
  • Runtime baselines cho kubelet/containerd.

SRE/Operations ​

Chịu trách nhiệm:

  • Theo dõi node health và incident response.
  • Vận hành runbook drain/repair/upgrade.
  • Đánh giá error budget liên quan node disruptions.

Application teams ​

Chịu trách nhiệm:

  • Thiết kế ứng dụng tương thích disruption (PDB, graceful shutdown, retries).
  • Khai báo requests/limits đúng thực tế.
  • Đảm bảo image và dependencies tương thích kiến trúc node mục tiêu.

Security/Compliance ​

Chịu trách nhiệm:

  • Chính sách dùng Confidential Nodes theo data classification.
  • Chuẩn registry trust, CA rotation, image provenance.
  • Kiểm soát thay đổi node-level có ảnh hưởng bảo mật.

Checklist tự đánh giá mức trưởng thành vận hành node ​

Mức 1 — Reactive ​

  • Chỉ xử lý khi node đã NotReady.
  • Không phân tách node pools theo workload profile.
  • Nâng cấp chủ yếu thủ công và thiếu đo lường tác động.

Mức 2 — Managed ​

  • Có dashboard conditions cơ bản.
  • Có maintenance windows và một số policy upgrade.
  • Có PDB cho dịch vụ quan trọng nhưng chưa đồng bộ toàn cục.

Mức 3 — Predictive ​

  • Cảnh báo sớm theo xu hướng pressure trước khi sự cố xảy ra.
  • Có playbook preemption, stuck drain, IP exhaustion.
  • Có ring-based rollout cho thay đổi node/runtime.

Mức 4 — Optimized ​

  • Runtime configs quản trị tập trung, versioned.
  • Cost/reliability/security được tối ưu theo từng pool class.
  • Có cơ chế kiểm chứng liên tục bằng game day và postmortem chất lượng cao.

Những câu hỏi kiến trúc bắt buộc trả lời trước khi lên production ​

  1. Node pool nào phục vụ workload critical và vì sao?
  2. Dung lượng Pod CIDR hiện tại chịu được tăng trưởng bao lâu nếu có surge/blue-green?
  3. Khi Spot preemption burst, dịch vụ nào vẫn phải giữ SLO và capacity floor là bao nhiêu?
  4. Kế hoạch rollback cho đợt nâng cấp node gần nhất là gì?
  5. Cluster có cơ chế phát hiện sớm drift kubelet/containerd không?
  6. Nếu một zone mất 30% node, ứng dụng còn đảm bảo quorum không?
  7. Các service có termination behavior thực sự phù hợp với shutdown budget chưa?
  8. Có quy trình chuẩn cho CA rotation của private registry không?

Nếu chưa trả lời rõ những câu hỏi này, chưa nên coi node lifecycle đã “production ready”.

Mapping nhanh chủ đề con với loại incident phổ biến ​

Loại incidentTriệu chứng chínhFile cần đọc trước
Node NotReady tăng nhanhPod Pending, scheduler thiếu node khả dụng01
Eviction dây chuyềnRestart cao, latency dao động01, 05
Upgrade gây gián đoạn lớnTăng 5xx trong rollout02
Drain bị kẹtNode không thể thay thế đúng lịch02
Spot bị thu hồi hàng loạtThroughput giảm đột ngột03
Migrate ARM gặp lỗi lạMột số pod không start được03
Scale fail dù còn quota VMPod Pending do IP/network04
Pod startup quá chậmReadiness timeout sau scale04, 05
Image pull thất bại diện rộngImagePullBackOff đồng loạt05

Tài liệu chính thức nên bám theo khi chapter này được cập nhật định kỳ ​

Khi cập nhật chapter theo phiên bản GKE mới, ưu tiên theo thứ tự:

  1. Tài liệu khái niệm chính thức của GKE (concepts).
  2. Tài liệu how-to có command/config hỗ trợ.
  3. Tài liệu tham chiếu API của trường cấu hình cụ thể.
  4. Tài liệu Kubernetes upstream cho hành vi nền (node, eviction, PDB, shutdown).
  5. Architecture Framework/Well-Architected để rà lại quyết định ở góc reliability/operations.

Danh sách URL neo chính:

Kết luận của chapter ​

Node lifecycle không phải phần “hậu cần” của Kubernetes, mà là lớp quyết định trực tiếp độ bền dịch vụ. Khi triển khai đúng, bạn sẽ đạt được ba lợi ích khó thay thế:

  1. Độ ổn định cao hơn khi thay đổi liên tục: upgrade, repair, scale không còn là sự kiện rủi ro cao.
  2. Giảm chi phí incident: sự cố còn xảy ra nhưng bị chặn sớm, blast radius nhỏ và thời gian xử lý ngắn hơn.
  3. Nền tảng để tối ưu cấp cao: có thể tự tin tối ưu Spot/ARM/Confidential theo mục tiêu business mà không phá vỡ reliability.

Cách dùng chapter hiệu quả nhất là biến từng mục thành năng lực vận hành cụ thể: policy, runbook, dashboard, game day và tiêu chí rollout/rollback rõ ràng. Khi đó chapter này không chỉ là tài liệu đọc, mà là “hệ điều hành vận hành node” cho toàn tổ chức.

FAQ của toàn chương ​

Chapter 6 nên được dùng như tài liệu học hay tài liệu vận hành? ​

Nên dùng theo cả hai, nhưng ưu tiên vận hành: mỗi mục cần được chuyển thành policy, dashboard, runbook hoặc checklist kiểm soát thay đổi.

Có cần áp dụng toàn bộ khuyến nghị cùng lúc không? ​

Không. Nên đi theo lộ trình trưởng thành: ổn định trước, rồi tối ưu dần. Cố làm tất cả cùng lúc dễ tạo rủi ro thay đổi chồng chéo.

Nếu tổ chức nhỏ, có cần chia nhiều node pool như chapter gợi ý? ​

Có thể bắt đầu ít hơn, nhưng vẫn nên tách tối thiểu pool critical và pool non-critical để giảm blast radius. Khi hệ thống lớn dần thì mở rộng taxonomy pool.

Làm sao biết chương này đã được áp dụng hiệu quả? ​

Bạn sẽ thấy các chỉ số vận hành cải thiện có thể đo được: ít incident node lặp lại hơn, thời gian phục hồi ngắn hơn, nâng cấp ổn định hơn, và chi phí vận hành ngoài giờ giảm.

Checklist triển khai chapter trong tổ chức ​

Tuần đầu tiên ​

  • Chốt owner cho node lifecycle domain.
  • Tạo dashboard node conditions và incident signals.
  • Chuẩn hóa runbook xử lý NotReady.

Tuần thứ hai đến thứ tư ​

  • Hoàn thiện policy nâng cấp node pools theo tier dịch vụ.
  • Thiết lập maintenance windows/exclusions theo lịch business.
  • Rà soát PDB và shutdown behavior của dịch vụ quan trọng.

Tháng thứ hai ​

  • Thử nghiệm Spot/ARM/Confidential trên canary pools.
  • Rà soát Pod CIDR headroom và boot disk profiles.
  • Đưa runtime config vào quy trình review/rollback chuẩn.

Tháng thứ ba trở đi ​

  • Thiết lập game day định kỳ cho các kịch bản node failures.
  • Đo maturity và cải tiến theo vòng lặp hàng quý.
  • Đồng bộ bài học postmortem vào tài liệu nội bộ.

Khi checklist này được duy trì đều đặn, chapter sẽ trở thành năng lực vận hành thật thay vì chỉ là nội dung lý thuyết.

Gợi ý cách dùng chapter cho workshop nội bộ ​

  • Buổi 1: mô phỏng incident NotReady và thực hành runbook.
  • Buổi 2: thiết kế upgrade policy cho 3 tier dịch vụ mẫu.
  • Buổi 3: bài toán cost vs reliability với Spot/ARM/Reservations.
  • Buổi 4: bài tập capacity planning với maxPodsPerNode và Pod CIDR.
  • Buổi 5: review runtime policy kubelet/containerd và kế hoạch cgroup v2.

Mỗi buổi nên kết thúc bằng quyết định cụ thể áp dụng vào môi trường thật, không dừng ở thảo luận lý thuyết.

Ghi chú vận hành dài hạn ​

Giá trị lớn nhất của chapter này đến từ tính lặp lại: cùng một loại sự cố phải được xử lý ngày càng nhanh hơn, với ít thao tác thủ công hơn và ít bất ngờ hơn. Khi team đạt được điều đó, chapter đã hoàn thành đúng mục tiêu của một production handbook.

Gợi ý duy trì chất lượng nội dung chapter ​

Nên đặt lịch rà soát nội dung chapter theo chu kỳ phát hành GKE và sau mỗi incident lớn liên quan node lifecycle. Mục tiêu là đảm bảo handbook luôn phản ánh thực tế vận hành mới nhất, không trở thành tài liệu “đúng trong quá khứ”.

Nhắc lại mục tiêu cốt lõi của chương ​

Khi đọc và áp dụng chương này, mục tiêu không chỉ là hiểu thuật ngữ mà là xây được năng lực vận hành lặp lại, có thể dự đoán, có thể kiểm soát rủi ro thay đổi ở lớp node. Đó là nền tảng để mọi chương sâu hơn về scheduler, networking và observability phát huy hiệu quả trong production.

Đó cũng là lý do Chapter 6 nên được xem là chương bắt buộc trước khi mở rộng vận hành đa cụm quy mô lớn.

Phần mở rộng này nhấn mạnh rằng chapter chỉ hoàn thành mục tiêu khi các nguyên tắc được chuyển thành hành động định kỳ trong vận hành: đo lường, kiểm thử, rà soát, cải tiến.

Năng lực này cần được duy trì qua nhiều chu kỳ phát hành để đảm bảo hệ thống luôn ổn định ngay cả khi quy mô, kiến trúc và đội ngũ thay đổi liên tục.