Kubernetes Kubelet 的 Cgroups 资源限制机制分析

前言

容器技术的两大技术基石，想必大家都有所了解，即 namespace 和 cgroups。但你知道 cgroups 是如何在 kubernetes 中发挥作用的吗？kubelet 都设置了哪些 cgroups 参数来实现对容器的资源限制的呢？本文就来扒一扒 Kubernetes kubelet 的 cgroups 资源限制机制。

层级化的资源限制方式

kubelet 基于 cgroups 的树形结构，采用层级式的方式管理容器的资源限制，如下图所示：

Node Level Cgroups

Node 层级的资源限制主要是为了避免容器过度占用系统资源，导致节点资源耗尽，影响系统级（如 systemd）和 Kubernetes 依赖组件（如 kubelet 和 containerd）的正常运行，可以通过预留系统资源的方式，确保容器使用的资源总量在控制的范围内。

system-reserved

• 默认行为：System Reserved Cgroups 默认不配置，需要通过参数显式启用
• 执行时机：每次 kubelet 启动时执行检查和设置

下表描述了 system-reserved 可能设置的 cgroups 限制：

上述表格中的资源限制数值均由参数 --system-reserved 控制，不再赘述。

kube-reserved

• 默认行为：Kube Reserved Cgroups 默认不配置，需要通过参数显式启用
• 执行时机：每次 kubelet 启动时执行检查和设置

下表描述了 kube-reserved 可能设置的 cgroups 限制：

上述表格中的资源限制数值均由参数 --kube-reserved 控制，不再赘述。

kubepods

• 默认行为：kubepods 默认启用配置，且无论如何都会刷新
  这是因为作为 Pods 顶级 cgroups 限制，操作系统默认设置的 cpu.shares=1024 或 cpu.weight=100 过小，很可能出现 CPU 限流，使容器性能变差，因此需要显式刷新。
• 执行时机：每次 kubelet 启动时执行检查和设置（部分参数同时会被 QoS Manager 周期性和触发式刷新）