cgroup 在层级中执行容器资源预算
Kubernetes 资源字段只有经过节点执行栈落实，才成为实际约束。在 Linux 上，kubelet 与容器运行时通过 cgroup 组织进程并配置资源控制器。最终形成的是一个层级，而不是简单贴在 Pod 上的单个数字。判断进程真正可以消耗多少资源之前，需要检查对应容器控制组及继承的约束，避免把清单意图直接等同于有效运行预算。 读取实际执行资源约束的控制器 在 cgroup v2 中，cpu.max 用配额与周期表示 CPU 带宽，单位是微秒。10000 100000 表示该组每个周期可使用相当于十分之一个 CPU 的时间。它不会把进程固定在一个核心上，也不会降低处理器时钟频率。组内如果存在多个可运行线程，就可能在同一周期中更快消耗完共同额度，然后等待下一段可用预算。 CPU weight 负责另一件事：在发生争用时，影响相应层级中有资格竞争的组之间的相对分配。Kubernetes 的 CPU 请求既参与调度，也可以影响这个权重。请求本身不是运行时硬上限，权重也不保证应用的墙钟延迟或独占核心。应把放置需求、相对份额和带宽上限分别理解，而不是都称为已经预留的 CPU。 内存控制器分别暴露限制与使用量。memory.max 描述控制组的硬内存边界，memory.current 报告当前记账使用。回收与 OOM 属于内存机制，不是 CPU 那样按周期进行的节流。应用堆大小也不能解释全部记账内存，调查限制问题时需要把运行时指标与控制器视图对应起来，关注额外进程、缓存和其他开销。 坏掉的样子 层级约束可能比某个本地文件显示的值更严格。子组没有本地 CPU 上限，仍可能受到祖先限制；容器的 cgroup 命名空间也可能隐藏部分层级。因此，不能看到本地 max 就推断可以无限使用整个节点。有效预算还取决于节点上下文与父级约束，容器内部可见的信息未必足以解释所有争用和节流。 ...