題幹與適用場景
平台團隊發現某租戶的批次容器會在高峰期擠壓線上服務。節點採用 cgroup v2，團隊只設定一個 memory limit，無法區分「應先回收」「應節流」和「必須終止」。請設計分層記憶體策略，說明保護邊界、事件監控和回滾方式。
面試官考察點
- 是否區分 memory.min/low 的保護、memory.high 的回收與節流、memory.max 的硬限制。
- 能否說明 memory.events 的階層統計與 memory.events.local 的差異。
- 是否處理 OOM 群組終止、子 cgroup 繼承、突發流量和 overcommit。
- 能否把核心介面映射到容器編排、告警和演練流程。
回答前需要釐清的問題
- 目標是保護關鍵工作負載、限制單一租戶，還是保證節點不被拖垮？
- 工作負載是延遲敏感、批次，還是允許被回收和重試的任務？
- cgroup 階層如何劃分，是否有共享的父 cgroup 和 sidecar？
- 是否使用 Kubernetes，requests 與 limits 如何映射到 cgroup v2？
- 發生 OOM 時希望殺單一行程、整個 cgroup，還是讓上層重建容器？
30 秒回答框架
我會把 memory.min/low 用於相對保護，把 memory.high 作為壓力閾值，讓回收和節流先發生，把 memory.max 作為最終硬上限。memory.oom.group 決定 OOM 時是否整組終止。策略必須按父子 cgroup 預算分配，監控 memory.current、memory.events 和 PSI，並在 canary、壓力測試和回滾中驗證。Kubernetes 層還要核對 requests/limits 到 cgroup v2 檔案的實際映射，不能只看 YAML。
分步驟深入解答
第一步：建立語義模型
memory.min 是硬保護邊界，低於該值的記憶體回收會盡量避免；memory.low 是盡力而為的保護，系統壓力大時可能被回收。memory.high 觸發回收和節流，但不會直接觸發 OOM killer；memory.max 是不可突破的限制，無法回收時可能進入 cgroup OOM。名稱相似的欄位不能用同一個 limit 取代。
第二步：分配父子預算
先為節點保留系統和關鍵服務預算，再給租戶父 cgroup 分配上限，最後為線上、批次和 sidecar 設定子 cgroup。子 cgroup 的保護不能無條件超過父級可用預算；應記錄每層的 current、events 和配置版本。對突發工作負載，給 high 留出可接受的工作集空間，避免短時尖峰直接變成 max OOM。
第三步：選擇 high 與 max 的關係
memory.high 適合讓系統先施加回收和節流壓力，應用可以觀察延遲、吞吐和事件後減速。memory.max 是最終安全閥，應按可恢復性設定。把 high 設得過低會持續節流，把 max 設得過高會把壓力推給父 cgroup 或節點；兩者都要用負載測試校準。
第四步：決定 OOM 群組策略
當服務由多個緊密協作行程組成時，memory.oom.group=1 可讓 OOM 處理按 cgroup 整組進行，避免只殺主行程留下不可用的輔助行程。獨立批次任務可能更適合單一行程退出並由佇列重試。無論選擇哪種方式，都要記錄退出原因、重啟次數和未完成工作，避免把 OOM 當成無害重試。
第五步：建立 memory.events 監控
memory.events 提供階層統計，子樹事件也可能計入父 cgroup；memory.events.local 只表示目前 cgroup 的本地事件。監控 high、max、oom、oom_kill 的增量，並關聯 memory.current、工作集、PSI、延遲和佇列年齡。讀取檔案時按 key 解析，不要依賴鍵的固定順序。
第六步：映射到容器編排
在 Kubernetes 上同時檢查 requests、limits、QoS 類別和節點 cgroup 模式。渲染後進入容器讀取 /sys/fs/cgroup 的實際值，確認執行時沒有覆寫策略。sidecar、init 容器和共享 emptyDir 的記憶體歸屬要單獨核對，否則業務容器看似有餘量，父 cgroup 可能已達到 high 或 max。
第七步：演練、發布與回滾
先在單節點 canary 上逐步降低 high，觀察節流和回收，再驗證 max 與 oom.group 的終止行為。告警應區分持續 high、首次 max 和實際 oom_kill。配置以版本化檔案發布，保留前一版本和事件快照；回滾先恢復預算，再處理已被殺的任務和佇列重試，避免只改 limit 卻留下節點壓力。
高品質示範回答
我會用 min/low 表達保護等級，用 high 觸發可觀測的回收和節流，用 max 作為不可突破的最終上限。父子 cgroup 先分配節點、租戶和工作負載預算，再按可恢復性決定 oom.group。監控 memory.events 的階層與本地差異，關聯 PSI、延遲、佇列和重啟；Kubernetes 端讀取容器內實際 cgroup 檔案確認映射。發布採用 canary、壓力演練和版本化回滾。
常見錯誤
- 把 memory.high 當成立即 OOM 的硬上限。
- 把 memory.low 當成永遠不會被回收的保證。
- 只看容器 YAML，不讀取執行時 cgroup 檔案。
- 把父 cgroup 的階層事件和目前 cgroup 的本地事件混為一談。
- OOM 後只重啟容器，不檢查佇列冪等、部分結果和重試風暴。
追問及應對
追問一：memory.high 觸發後會發生什麼？
核心會對該 cgroup 施加回收和節流壓力，行程可能繼續執行但延遲上升。它不是直接呼叫 OOM killer 的開關，應配合 high 事件、PSI 和業務延遲觀察。
追問二：為什麼還需要 memory.max？
high 允許工作負載在壓力下退讓，max 提供最終邊界，防止無法回收的增長無限佔用父級或節點。max 需要和可恢復性、重啟策略一起設計。
追問三：memory.events 為什麼會重複計數？
父 cgroup 的 memory.events 預設包含子樹事件，而 memory.events.local 只統計目前層級。監控應明確使用哪一種，並按層級去重告警。
追問四：何時設定 memory.oom.group？
當同一 cgroup 內的行程必須整體存活或整體重建時使用；彼此獨立的任務可選擇單一行程退出。兩者都必須驗證清理、重試和可觀測性。
追問五：如何證明 Kubernetes 映射正確？
在目標節點讀取容器所在 cgroup 的 memory.min、memory.low、memory.high、memory.max 和 events，與渲染後的 requests、limits、QoS 和執行時配置逐項比對，再進行壓力演練。