26 的 Pod UID告诉我们去哪儿找宿主进程；06和07告诉我们实际限制要到内核层核验。Kubernetes 的 requests 用于资源预留/调度和相应资源权重，limits 则用于节点限制机制；节点是否接受某 Pod、容器会否 CPU 节流、谁因内存不足被杀、Pod 会否被驱逐，是四类不同事件。

不要把所有失败叫 OOM

调度阶段因资源 requests 不满足而 Pending，没有理由从宿主寻找已运行进程的 cpu.stat。容器已启动后超过 CPU limit，可在所选 cgroup 的 cpu.stat 观察节流增量，应用仍可能继续运行；达到 memory limit 可能发生组内内存事件与进程终止，要对照 memory.events、container status 和相应节点事件；节点整体内存/磁盘压力下的 eviction 又由 kubelet 决策，不等于同一个 memory.max 触发点。不同 Kubernetes 与 cgroup 版本的 QoS、CPU weight、OOM 和驱逐细节有版本前提，不能机械套一个表格。

专用 kind 节点正例用两个有界请求负载分别设置资源，按 UID 找到应用 cgroup 与 cpu.max/memory.max，对照限额与计数器增量；失败对照分别单独制造调度等待、CPU 节流、受控内存事件和专用节点压力，观察事件而不是预先指定退出码。压力只施加在专用 VM，自定义上限及控制台恢复路径必须先固定。补跑入口与有界探针避免无上限申请。本云端 cgroup v1 只读且无 kubelet，所有节点实测 NOT_RUN。

现象 核对层 不可推出
Pod Pending 调度条件和节点可分配量 CPU 已被节流
响应慢且 throttled 增加 对应 PID 的 cgroup 与应用耗时 所有延迟都由 CPU 造成
容器退出 137 memory.events、节点事件 一定是内存 limit OOM

练习

  1. 先预测 CPU request 提高但 limit 不变、在节点无竞争时 cpu.stat 是否必然变化；分开比较调度与节流证据。
  2. 先预测节点 eviction 与容器 memory limit OOM 的对象/事件差别，在专用节点各跑一个受控案例并核对 UID/PID/cgroup。

上一篇：26：Pod 节点执行；下一篇：28：Running 与 Ready。

系列总目录：从进程隔离到运行时与编排。

参考资料