My Awesome Project

Appearance

Chương 8: GKE Scheduler — Thuật Toán, Affinity & Resource Model ​

Vì sao chương này quyết định độ ổn định của cluster ​

Phần lớn sự cố "Pod kẹt Pending" mà các đội vận hành GKE gặp phải không phải do thiếu tài nguyên thật, mà do mô hình tinh thần sai về cách scheduler ra quyết định. Một engineer khai báo requests quá tay, đặt một podAntiAffinity bắt buộc trên topology key sai, hoặc quên rằng node pool đang mang một taint — và scheduler, vận hành đúng như thiết kế, từ chối đặt Pod. Triệu chứng nhìn giống "hết tài nguyên" nhưng nguyên nhân gốc là một ràng buộc do chính người dùng tạo ra.

kube-scheduler là một trong những control plane component được Google quản lý hoàn toàn trên GKE: bạn không SSH vào nó, không sửa file cấu hình của nó trên cluster Standard, và trên Autopilot bạn thậm chí không thấy node. Nhưng chính vì không chạm được vào scheduler, việc hiểu sâu thuật toán nội tại của nó càng quan trọng — vì cách duy nhất để điều khiển scheduler là qua spec của Pod (requests, affinity, tolerations, topology spread, priority) và qua cấu trúc node pool. Mọi đòn bẩy đều gián tiếp, và mọi đòn bẩy sai đều biểu hiện thành cùng một triệu chứng mơ hồ.

Theo tài liệu Kubernetes, kube-scheduler chọn node cho Pod qua một thao tác hai bước: filtering (lọc ra các node khả thi) và scoring (chấm điểm để chọn node tốt nhất) (kube-scheduler). Đằng sau hai bước đó là Scheduling Framework — kiến trúc plugin biên dịch thẳng vào scheduler, với hơn một chục extension point (Scheduling Framework). Chương này mổ xẻ toàn bộ guồng máy đó tới mức bạn có thể nhìn một Pod Pending và suy ra chính xác plugin nào đã loại node nào, vì sao, và sửa ở đâu.

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

  • Đã đọc Chương 6 (Node Lifecycle & Pool Management): node pool, taints mặc định của GKE, max-pods-per-node, capacity của node.
  • Đã đọc Chương 7 (Networking Internals): scheduling quyết định Pod nằm ở node nào, ảnh hưởng same-node vs cross-node path và phân bố backend của Service.
  • Nắm vững Kubernetes resource model: requests vs limits, đơn vị CPU (millicore), đơn vị memory (Mi/Gi).
  • Hiểu cơ bản về cgroups Linux (CFS quota, OOM killer) — sẽ đào sâu trong chương.

Mức độ sâu ​

5/5 — Chương đi tới mức từng extension point của Scheduling Framework, cơ chế ba hàng đợi nội bộ (activeQ/backoffQ/unschedulablePods), công thức tính skew của topology spread, cơ chế CFS quota throttling và OOM kill ở tầng kernel, thuật toán chọn victim khi preemption, và cách Autopilot thực thi tỷ lệ CPU:memory. Mọi tuyên bố kỹ thuật đối chiếu trực tiếp tài liệu Kubernetes và Google Cloud.

Cấu trúc chapter ​

1. Scheduler Architecture & Workflow — Scheduling Framework, Cycle & Queue ​

Bộ khung vận hành của scheduler:

  • Hai pha lớn: scheduling cycle (chọn node) vs binding cycle (ghi quyết định)
  • Toàn bộ extension point theo thứ tự: PreEnqueue → QueueSort → PreFilter → Filter → PostFilter → PreScore → Score → NormalizeScore → Reserve → Permit → PreBind → Bind → PostBind
  • Vì sao scheduling cycle chạy tuần tự còn binding cycle chạy song song
  • Optimistic locking và assume cache: scheduler "giả định" bind thành công để không chặn
  • Ba hàng đợi: activeQ, backoffQ, unschedulablePods — Pod di chuyển giữa chúng thế nào
  • Exponential backoff, QueueingHints, flush định kỳ
  • Scheduler metrics: pending_pods, scheduler_pending_pods, scheduling_attempt_duration_seconds, queue depth

2. Filter & Score Plugins — Lọc Node & Chấm Điểm ​

Bản chất thuật toán của hai pha cốt lõi:

  • Filter plugins: NodeResourcesFit, NodeAffinity, TaintToleration, PodTopologySpread, VolumeBinding, NodePorts, NodeUnschedulable
  • Vì sao Filter chạy song song trên các node, dừng sớm khi một plugin loại node
  • Score plugins: NodeResourcesFit (LeastAllocated vs MostAllocated vs RequestedToCapacityRatio), NodeResourcesBalancedAllocation, ImageLocality, InterPodAffinity, NodeAffinity
  • Spread (LeastAllocated) vs bin-packing (MostAllocated): trade-off độ bền vs chi phí
  • GKE autoscaling profile optimize-utilization đổi scheduler thành bin-packing (gke.io/optimize-utilization-scheduler)
  • NormalizeScore và trọng số plugin

3. Node Affinity & Inter-Pod Affinity/Anti-Affinity ​

Ràng buộc "hút" Pod về đúng chỗ:

  • nodeAffinity: required vs preferred, operators (In, NotIn, Exists, Gt, Lt), weight 1–100
  • nodeSelectorTerms (OR) vs matchExpressions (AND)
  • Inter-pod affinity: topologyKey, labelSelector, namespaceSelector
  • Pod anti-affinity: use case HA, vì sao chi phí O(pods × namespaces) ở scale lớn
  • IgnoredDuringExecution: vì sao label đổi sau scheduling không di dời Pod
  • Anti-pattern: required anti-affinity hostname cho replica > số node

4. Pod Topology Spread Constraints — Phân Bố Theo Failure Domain ​

Cơ chế phân bố hiện đại thay cho anti-affinity:

  • maxSkew, topologyKey, whenUnsatisfiable (DoNotSchedule vs ScheduleAnyway)
  • Công thức skew = (số Pod khớp trong domain hiện tại) − (global minimum)
  • minDomains: ép tối thiểu số domain, global minimum coi như 0 khi thiếu domain
  • nodeAffinityPolicy, nodeTaintsPolicy, matchLabelKeys (rolling update)
  • Default cluster-level constraints của Kubernetes
  • So sánh trực tiếp với podAntiAffinity: vì sao topology spread linh hoạt hơn

5. Taints & Tolerations — Ràng Buộc "Đẩy" Node ​

Mặt đối nghịch của affinity — node tự bảo vệ:

  • Ba effect: NoSchedule, PreferNoSchedule, NoExecute — khác biệt thời điểm tác động
  • NoExecute + tolerationSeconds: đuổi Pod đang chạy, timing eviction
  • operator Equal vs Exists
  • Taint-based eviction: node condition taints (not-ready, unreachable, memory-pressure...)
  • Default toleration 300s do admission controller thêm — ý nghĩa với node failure
  • Taints mặc định của GKE: GPU node, Spot, ARM, dedicated node pool

6. Resource Model, QoS & Node-Pressure Eviction ​

Nền tảng tài nguyên định hình mọi quyết định scheduling:

  • requests vs limits: scheduler chỉ nhìn requests, không nhìn limits
  • CPU compressible: CFS quota throttling, chu kỳ 100ms, vì sao limit CPU thấp gây latency
  • Memory incompressible: OOM kill khi vượt limit, không có throttle
  • QoS classes: Guaranteed, Burstable, BestEffort — phân loại tự động
  • Node-pressure eviction: signals (memory.available, nodefs.available...), soft vs hard threshold
  • Thứ tự eviction theo QoS và priority, "usage above requests"
  • Vì sao node-pressure eviction KHÔNG tôn trọng PodDisruptionBudget

7. Pod Priority & Preemption ​

Khi cluster đầy và phải hy sinh Pod:

  • PriorityClass: value (≤ 1 tỷ), globalDefault, preemptionPolicy (Never vs PreemptLowerPriority)
  • system-cluster-critical, system-node-critical
  • Cơ chế preemption: chọn node, chọn victim, nominatedNodeName
  • PodDisruptionBudget được tôn trọng "best-effort" khi preemption
  • Graceful termination tạo khoảng trống giữa preempt và schedule
  • Cross-node preemption không xảy ra, starvation, non-preempting pods
  • ResourceQuota giới hạn tiêu thụ PriorityClass cao

8. Extended Resources & GPU Scheduling ​

Lập lịch phần cứng đặc biệt:

  • Extended resources: vì sao phải đặt requests = limits
  • GPU trên GKE: nvidia.com/gpu trong limits, node selector cloud.google.com/gke-accelerator
  • Taint nvidia.com/gpu=present:NoSchedule + ExtendedResourceToleration admission controller
  • Device plugin DaemonSet, cài driver (gpu-driver-version)
  • GPU sharing: time-sharing, multi-instance GPU (MIG), trade-off
  • Vì sao GPU không bao giờ là Burstable

9. GKE Autopilot Scheduling, Custom ComputeClasses & Scheduler Extenders ​

Lớp scheduling đặc thù GKE và mở rộng:

  • Autopilot: thực thi tỷ lệ CPU:memory theo compute class (general-purpose 1:1–1:6.5...)
  • Tự điều chỉnh request nhỏ, từ chối workload vượt max
  • Compute classes: general-purpose, Balanced, Scale-Out, Accelerator, Performance
  • Custom ComputeClasses: priorities/fallback, mapping VM family, activeMigration, consolidation
  • nodePoolAutoCreation, whenUnsatisfiable (DoNotScaleUp 1.33+)
  • Scheduler extenders (webhook) vs scheduler plugins: vì sao plugins thắng

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

Nếu bạn đang debug một Pod kẹt Pending ​

  1. Bắt đầu từ file 1 để hiểu Pod đang ở hàng đợi nào và vì sao chưa được thử lại.
  2. Sang file 2 để biết plugin nào loại node ở pha Filter (đọc kubectl describe pod events đối chiếu plugin).
  3. Nếu liên quan affinity/anti-affinity đọc file 3; topology spread file 4; taint file 5; thiếu tài nguyên thật file 6.

Nếu bạn đang thiết kế node pool & resource strategy mới ​

  1. File 6 (resource model/QoS) để khóa chuẩn requests/limits trước khi onboard workload.
  2. File 5 (taints) để thiết kế dedicated node pool và isolation.
  3. File 4 (topology spread) để thiết kế HA mặc định cho mọi Deployment.

Nếu bạn đang tối ưu chi phí/độ bền ở scale lớn ​

  1. File 2 (spread vs bin-packing) và file 9 (Autopilot/ComputeClasses) để chọn chiến lược đóng gói.
  2. File 7 (priority/preemption) để phân tầng workload critical vs batch.
  3. File 8 (GPU) nếu chạy AI/ML — đóng gói GPU sai là lãng phí lớn nhất.

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
Chuẩn requests/limitsĐóng gói, throttling, OOMPending giả, latency do throttle, OOM kill6
Spread vs bin-packingChi phí vs blast radiusQuá phân tán (đắt) hoặc quá gom (mất node là gãy)2, 9
Topology spread mặc địnhĐộ bền khi mất zone/nodeMất zone là mất toàn bộ replica4
Dedicated node pool qua taintIsolation workloadWorkload critical lẫn vào node sai5
PriorityClass phân tầngWorkload critical luôn được chỗBatch chiếm chỗ critical, hoặc starvation7
Autopilot vs StandardMức kiểm soát schedulingSpec sai bị Autopilot từ chối/điều chỉnh9

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
Pod Pending dù còn CPU/RAM0/N nodes available với lý do affinity/taint02, 03, 05
Replica dồn hết vào một zoneMất zone là mất service04
Latency tăng đột ngột không rõ lý doCPU throttling do limit thấp06
Pod bị OOMKilled lặp lạiVượt memory limit06
Pod bị evict hàng loạt lúc node căngNode-pressure eviction06
Batch job đẩy service production raPreemption sai cấu hình priority07
GPU node nhận Pod không cần GPUThiếu taint/toleration đúng05, 08
Autopilot từ chối DeploymentVượt max hoặc sai tỷ lệ CPU:memory09

Năm sai lầm xuyên suốt thường gặp ở cấp chương ​

Trước khi đi vào từng file, đây là các sai lầm lặp lại nhiều nhất, cắt ngang mọi chủ đề của chương:

  1. Nhầm "Pending" với "hết tài nguyên". Phần lớn Pending là do ràng buộc người dùng tạo (affinity, taint, topology spread), không phải do cluster thật sự đầy. Luôn đọc đúng dòng lý do trong events (file 1, 2).
  2. Đặt requests theo cảm tính, bỏ trống limits hoặc đặt limit CPU quá thấp. Requests sai làm scheduler quyết định sai; limit CPU thấp gây throttling âm thầm phá latency (file 6).
  3. Dùng requiredDuringScheduling anti-affinity ở hostname cho số replica > số node. Một số replica sẽ kẹt Pending vĩnh viễn — đây là anti-pattern kinh điển; dùng topology spread thay thế (file 3, 4).
  4. Không phân tầng priority. Khi cluster đầy, không có cách nào để service production thắng batch job, hoặc tệ hơn batch preempt nhầm production (file 7).
  5. Mặc định bin-packing tối đa để tiết kiệm. Gom Pod vào ít node nhất nghe rẻ, nhưng blast radius khi mất một node tăng vọt — cân bằng với topology spread (file 2, 4).

Cross-reference với Google Cloud Architecture Framework ​

  • Reliability: phân bố Pod qua failure domain (topology spread), priority phân tầng, và tránh single point of failure ở tầng đóng gói (Reliability pillar).
  • Cost optimization: bin-packing và Autopilot/ComputeClasses giảm lãng phí, nhưng phải đánh đổi với độ bền (Cost optimization).
  • Performance optimization: chuẩn requests/limits đúng tránh throttling và OOM, định hình SLO latency (Architecture Framework).

References chung của chapter ​

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

  1. Mọi workload đã có requests đặt đúng theo đo đạc thực, không phải đoán?
  2. Service production đã có topology spread qua zone để chịu được mất một zone chưa?
  3. Đã phân tầng PriorityClass để critical luôn thắng batch khi cluster đầy chưa?
  4. Có dedicated node pool nào cần cô lập qua taint, và workload tương ứng đã có toleration?
  5. Chiến lược đóng gói là spread hay bin-packing, và blast radius khi mất một node có chấp nhận được?
  6. Nếu dùng GPU, đã hiểu vì sao GPU phải requests = limits và node có taint đúng?
  7. Nếu dùng Autopilot, spec đã tuân thủ tỷ lệ CPU:memory của compute class chưa?

Nếu chưa trả lời rõ các câu hỏi này, chiến lược scheduling của cluster chưa nên coi là "production ready".

Bảng thuật ngữ then chốt của chương ​

Thuật ngữÝ nghĩa ngắn gọn
Scheduling cyclePha chọn node, chạy tuần tự một Pod tại một thời điểm (file 1)
Binding cyclePha ghi quyết định, chạy song song nhiều Pod (file 1)
activeQ / backoffQ / unschedulablePodsBa hàng đợi nội bộ của scheduler (file 1)
Filter / ScoreHai pha: lọc node khả thi, chấm điểm chọn tốt nhất (file 2)
LeastAllocated / MostAllocatedChiến lược chấm điểm: spread vs bin-packing (file 2)
nodeAffinity / podAffinityRàng buộc hút Pod theo label node/Pod (file 3)
topologySpreadConstraintsPhân bố Pod đều qua failure domain (file 4)
Taint / TolerationNode đẩy Pod / Pod chấp nhận taint (file 5)
QoS classGuaranteed/Burstable/BestEffort, quyết định thứ tự evict (file 6)
CFS quotaCơ chế throttle CPU theo limit ở kernel (file 6)
PreemptionĐuổi Pod priority thấp để nhường chỗ Pod cao (file 7)
ComputeClassProfile node provisioning của GKE (file 9)

Kết luận của chapter ​

Scheduler là một hệ thống tất định: với cùng spec Pod, cùng trạng thái cluster, nó luôn ra cùng quyết định. Sự "bí ẩn" mà các đội gặp phải không nằm ở scheduler mà nằm ở khoảng cách giữa mô hình tinh thần của họ và thuật toán thật. Mục tiêu của chương này là xóa khoảng cách đó: khi bạn hiểu Filter loại node thế nào, Score chấm điểm ra sao, ba hàng đợi vận hành thế nào, và các ràng buộc (affinity, taint, topology spread, priority, resource) tương tác với nhau ra sao, thì mỗi Pod Pending chuyển từ "bí ẩn nhiều giờ" thành "đọc events, khớp plugin, sửa spec trong vài phút".

Cách dùng chương hiệu quả nhất là biến từng file thành một chuẩn vận hành: resource model thành policy requests/limits bắt buộc, topology spread thành template HA mặc định, taint thành chuẩn dedicated pool, priority thành phân tầng workload versioned, và Autopilot/ComputeClasses thành chiến lược đóng gói có lý do rõ ràng. Khi đó scheduler không còn là hộp đen mà là một công cụ bạn điều khiển chính xác qua spec.