cgroups在容器集群调度中的资源保障机制

cgroups 是 Linux 内核提供的资源隔离与限制机制，它本身不负责调度，但在容器集群（如 Kubernetes）中，是实现资源保障的底层基石——调度器决定“把容器放到哪台节点”，而 cgroups 负责在节点上“确保它只用承诺的 CPU、内存等资源”。

资源约束落地：从 Pod 配置到 cgroups 层级树

Kubernetes 中为 Pod 设置 requests 和 limits 后，kubelet 会将其翻译为具体的 cgroups 参数，并写入对应子系统路径。例如：

CPU 限制 → cpu.max（cgroup v2）或 cpu.cfs_quota_us/cpu.cfs_period_us（v1） 内存限制 → memory.max（v2）或 memory.limit_in_bytes（v1） 内存 + swap 限制 → memory.swap.max（v2，默认禁用 swap）

这些值最终映射到容器对应的 cgroup 目录（如 /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/podxxx/…/），由内核强制执行。

QoS 分级与 cgroups 策略绑定

Kubernetes 根据 requests/limits 的设置将 Pod 划分为 Guaranteed、Burstable、BestEffort 三类，每类触发不同的 cgroups 行为：

Guaranteed：requests == limits → 分配独占 CPU 配额（cpu.weight 固定）、内存硬限制（OOM 时优先保护） Burstable：requests < limits → 内存使用超 requests 后进入压力队列；CPU 共享权重按 requests 比例分配 BestEffort：无 requests/limits → 归入默认 cgroup，OOM 时最先被 kill，CPU 权重最低

这种分级不是调度策略本身，而是通过 cgroups 的资源担保强度，影响节点上实际运行时的公平性与稳定性。

资源回收与干扰抑制：memory.pressure & cpu.weight 动态调节

现代容器运行时（如 containerd + systemd cgroup driver）支持基于压力信号的主动干预：

当 memory.current 接近 memory.max，内核上报 memory.pressure 高压事件，kubelet 可触发驱逐或通知应用降载 在 cgroup v2 下，cpu.weight 支持动态调整：高优先级 Pod 可临时提升 weight，抢占更多 CPU 时间片（需配合调度器亲和性/优先级配置） IO 限速（io.max）和设备访问控制（devices.list）也通过 cgroups 实现，防止 noisy neighbor 干扰

多租户隔离强化：cgroup v2 + unified hierarchy

相比 v1，cgroup v2 提供统一层级结构、更细粒度的资源计量（如 per-cpu memory usage）、以及更强的子树控制能力，这对多租户集群尤为关键：

避免 v1 中不同子系统（cpu、memory、blkio）挂载点不一致导致的策略错位 支持 memory.low 设置“软限制”，保障关键服务在内存紧张时仍能获得基本资源 结合 systemd 的 scope 单元，可将整个 Pod 或命名空间绑定到指定 cgroup，便于审计与追踪

生产环境推荐启用 cgroup v2，并通过 kubelet 参数 –cgroup-driver=systemd 与容器运行时对齐。