cgroups 是 Linux 内核实现资源隔离与限制的底层机制，Kubernetes 通过 kubelet 将 Pod 的 requests/limits 转换为 cgroups 参数（如 cpu.max、memory.max），并依 QoS 分级（Guaranteed/Burstable/BestEffort）配置不同 cgroups 策略，结合 v2 统一层级、memory.pressure 监控、cpu.weight 动态调节等能力，保障多租户集群的资源公平性、稳定性与隔离性。
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
- 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 与容器运行时对齐。
