這份導讀與系列文章，是寫給已經知道 Kubernetes 基礎操作，想進一步了解它內部如何運作的人。如果你已經會用 kubectl 部署 Deployment、查看 Pod 狀態和 log，接下來想弄懂這些操作背後發生了什麼，可以從這裡開始。
系列沿著「提交資源之後，誰做決定、誰執行，以及最後如何落到 Linux 容器」這條路往下看。重點是串起各個元件的責任與協作方式，讓熟悉的操作有更具體的解釋。
從 Controller 開始
Deployment 如何變成 Pod？從兩個 Controller 理解 Reconcile 從「刪掉 Pod，為什麼又長回來」出發，拆開 Deployment 與 ReplicaSet 的分工，再往下看 Watch、Informer、queue 與快取延遲。
這篇先追到 Pod 物件建立。讀完後，可以試著回答：Controller 怎麼知道有變化？收到通知後，為什麼還要重新檢查狀態？兩個 Controller 又如何透過資源物件協作？
接著看排程
Pod 建立之後，要跑在哪裡？理解 Scheduler 的決策與交接 接在 Pod 物件建立之後，從「新副本一直 Pending，CPU 卻很閒」的情境出發，跟著一個 Pod 走完篩選、評分與 binding，再回來判斷該先改哪裡。想親手驗證的話，動手做：在 kind 重現 Pod 排不上會在本機做出同一個狀態，逐一試每種處理方式。
讀完後，可以試著回答：requests 與實際使用量在排程時各扮演什麼角色？Filtering 與 Scoring 各自決定什麼？Pod 排不上時，哪些改動只是讓它取得 Node，哪些才真正解決問題？
接著看 CPU limit
CPU 才用三成，為什麼還被 throttle？拆開 CPU limit 的 100ms 配額 接在 Pod 排上 Node 之後，從「延遲很高，儀表板上的 CPU 卻很閒」出發，看 CPU limit 與 request 在 Node 上變成哪些 cgroup 設定、kernel 怎麼執行它們，再比較幾種處理方式的效果與代價。想親手驗證的話，動手做：在 kind 重現「CPU 才用三成卻被 throttle」會在本機做出同一個狀態，並實測增加副本、提高 limit，以及 Node 忙碌時的差別。
讀完後，可以試著回答：為什麼平均使用率低和 throttle 可以同時成立？throttle 的指標該怎麼讀？為什麼只調高 limit 不一定有用？面對瞬間的突發，增加副本和提高 limit 各有什麼代價？
接著往哪些機制深入？
後續會以這些問題作為寫作方向，依實際查證與討論逐篇整理。以下尚未成文，不代表已有完整教材；完成的文章會加入下方清單。
| 主題 | 想釐清的問題 |
|---|---|
| 記憶體與資源管理 | 記憶體的 request 與 limit 如何落到 cgroup？用量超過 limit 時，為什麼不是像 CPU 一樣變慢，而是被終止？ |
| OOM、驅逐與搶占 | OOMKilled、node-pressure eviction 與 preemption 分別由誰觸發？QoS、Priority 與 PDB 各自處理什麼問題？ |
| 從 kubelet 到容器 | 排程之後 kubelet 如何接手？CRI、containerd、runc 分別負責哪一段？CNI 與 CSI 又在哪裡參與？ |
| Pod 與 Linux 隔離機制 | namespace 與 cgroup 解決什麼問題？Pod sandbox 是什麼？同一個 Pod 裡的 containers 共享哪些資源？ |
| 重啟與重建 | Container restart 和 Pod 重建差在哪裡？從物件身分與執行狀態，可以觀察到哪些差異？ |
這些機制也會回到實際判讀：看到 Pending、ContainerCreating、CPU 延遲或記憶體問題時，先辨認負責的元件，再找能支持判斷的證據。
本系列文章
- CPU 才用三成，為什麼還被 throttle？拆開 CPU limit 的 100ms 配額
RD 回報延遲很高，儀表板上的 CPU 卻很閒。從 cgroup 的 100ms 配額，看 CPU limit 在 Node 上怎麼被執行，以及該怎麼處理。
- 動手做：在 kind 重現「CPU 才用三成卻被 throttle」
用一次性的本機叢集讀出 cpu.max 與 cpu.stat，做出成群請求被 throttle 的服務，再實測 GOMAXPROCS、增加副本、提高 limit、cpu.weight，以及 Node 忙碌時的差別。
- Pod 建立之後，要跑在哪裡？理解 Scheduler 的決策與交接
新副本一直 Pending，CPU 卻很閒。拆開 Scheduler 的篩選、評分與指派，找出它被什麼擋下。
- 動手做：在 kind 重現 Pod 排不上，逐一檢驗五種處理
用一次性的本機叢集做出「CPU 很閒，新副本卻 Pending」的狀態，讀懂 FailedScheduling，再看每種改法讓 Pod 落到哪裡。
- Deployment 如何變成 Pod？從兩個 Controller 理解 Reconcile
從 Controller 的分工，理解 Watch、快取、工作佇列與滾動更新如何串起來。