浅谈Kubernetes在systemd cgroup模式下的Slice/Scope组织结构

在 Kubernetes 生产环境中，容器资源隔离是否可靠，并不取决于我们写了多少resources.limits，而取决于：

kubelet、container runtime（containerd / runc）和 systemd 是否使用了同一套 cgroup 管理体系

本文通过实际运行的 K8S 节点，结合systemd-cgls的实际输出，从工程角度讲解：

• systemd 下的slice / scope 是什么
• Kubernetes 的Pod / QoS / Container是如何映射到 cgroup 的
• 每一层是谁创建的、管什么资源
• 以及如何在机器上验证集群是否处在“正确状态”

一、背景：为什么要关心 systemd cgroup？

在现代 Linux 发行版（Ubuntu / RHEL / 麒麟 / 欧拉等）中：

• systemd 是默认的进程管理器
• cgroup（尤其是 cgroup v2）通常由 systemd 统一管理

Kubernetes 在这些系统上，如果配置正确，会形成一棵结构清晰、可观测且可预测的 cgroup 树，其中：

• kubelet 负责声明资源模型
• containerd / runc 负责创建容器进程
• systemd 负责真正落地 cgroup 层级

如果这三者cgroup 管理方式不一致，则会出现：

• Pod 启动失败
• CPU / 内存 的 requests / limits 不生效
• OOM 行为异常
• 资源统计混乱

二、slice / scope 到底是什么？

在 systemd 的世界里，所有进程都被放进 cgroup，其中有两种核心cgroup单元：

（1）Slice（.slice）

• 本质是cgroup目录
• 用于分组
• 资源限制可以向下继承

例如：

• kubepods.slice
• kubepods-burstable.slice

可以理解为：“一组进程的父目录”

（2）Scope（.scope）

• 用于承载一个具体的进程树
• 生命周期通常由外部程序（如runc）触发

例如：

• cri-containerd-xxx.scope

可以理解为：“某一个容器实例”

slice = 分组（目录），scope = 具体对象（容器 / 进程）

三、Kubernetes 在 systemd 下的标准 cgroup 树结构

当满足以下条件时：

• kubelet 使用--cgroup-driver=systemd
• containerd / runc 设置SystemdCgroup = true

Kubernetes 会在 systemd 中形成如下结构：

systemd └── kubepods.slice ├── kubepods-burstable.slice │ └── kubepods-burstable-pod<uid>.slice │ └── cri-containerd-<cid>.scope │ └── container process ├── kubepods-besteffort.slice │ └── ... └── kubepods-pod<uid>.slice (Guaranteed Pod)

四、systemd-cgls 输出解析

systemd-cgls是 Linux 系统中用于以树状结构显示 systemd 控制组（cgroups）层级的命令行工具。它帮助用户直观地查看当前系统中由systemd 管理的 cgroup 层级结构，包括服务、用户会话、容器等资源分组情况。

当在K8S节点上执行：

systemd-cgls

得到（节选）：

kubepods.slice ├─kubepods-podxxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx.slice │ └─cri-containerd-xxxxxxxxxxx....scope │ ├─362594 ./bin/xxxxservice_daemon │ ├─663693 xxx_backend │ └─664542 xxx_backend ├─kubepods-burstable.slice │ └─kubepods-burstable-podxxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx.slice │ └─cri-containerd-xxxxxxxxxx....scope │ └─xxx_backend └─kubepods-besteffort.slice └─kubepods-besteffort-podxxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx.slice └─cri-containerd-xxxxxxxxxx....scope └─node_exporter

关键点

• 一 Pod 一个 slice
• 一容器一个 scope
• QoS（Guaranteed / Burstable / BestEffort）体现在slice 层级

五、逐层拆解：每一层是谁创建的？管什么？

（1）kubepods.slice—— Kubernetes 的 cgroup 总入口

• 创建者：kubelet（通过 systemd D-Bus 接口）

• 含义：

  “这个节点上，所有 Kubernetes Pod 的 cgroup，都必须在这里”

• 作用：

  • 统一统计节点 Pod 资源
  • systemd 层面的集中管理

一般不建议在这一层施加资源限制。

（2）kubepods-burstable / besteffort.slice—— QoS 分组层

Kubernetes 会根据 Pod 的资源配置自动分类：

对应的 systemd 分组：

• kubepods-guaranteed.slice（有些版本直接显示在根下）
• kubepods-burstable.slice
• kubepods-besteffort.slice

这一步是K8S QoS 策略真正落地的地方，OOM 优先级、资源竞争顺序，都与此有关。

（3）kubepods-pod<uid>.slice—— 单个 Pod 的 cgroup

• 一 Pod 一 slice
• <uid>是 Pod UID（systemd 中-被转义成_）
• 这是 Pod 级资源控制的核心层

作用包括：

• Pod 级 CPU / memory 限制
• Pod 级资源统计
• Pod 内多个容器的“共同父 cgroup”

Pod 本质是一组容器，所以必须有这一层。

（4）cri-containerd-xxx.scope—— 单个容器实例

• 创建者：containerd / runc（通过 systemd）
• 一容器一 scope
• scope 里包含：
  • 容器主进程
  • 容器内 fork 出来的所有子进程

例如，服务容器中：

cri-containerd-xxx.scope ├─xxxservice_daemon ├─xxx_backend ├─xxx_backend

多进程并不意味着多个容器，而是同一容器内的进程树。

六、Guaranteed Pod 的验证

在 systemd 中，这个 Pod 直接挂在kubepods.slice下：

kubepods-podxxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx.slice

我们进一步通过 Kubernetes API 验证：

kubectl get pod -A\-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,UID:.metadata.uid,QOS:.status.qosClass\--no-headers\|grepxxxxxxxx(注：对应pod编号的前八位)

输出：

xxx-inference xxx-deployment-... xxxxxxxx(注：对应pod编号的前八位)-... Guaranteed

说明：这是一个 Guaranteed Pod，同时也解释了为什么它不在burstable / besteffort分组下。

七、如何在任何节点上验证集群是否“健康”

1️⃣ 查看 cgroup 树是否是 slice / scope 结构

systemd-cgls|grepkubepods -n

2️⃣ 确认 runtime 是否启用 systemd cgroup

containerd config dump|grepSystemdCgroup

应为：

SystemdCgroup = true

3️⃣ 确认 kubelet 使用 systemd

ps-ef|grepkubelet

我们会看到类似：

/usr/bin/kubelet\--config=/var/lib/kubelet/config.yaml

然后，

cat/var/lib/kubelet/config.yaml|grep-i cgroup

看到cgroupDriver: systemd

八、结论

Kubernetes 的资源模型从根本上讲是 systemd + cgroup 真正跑出来的

如果我们在 systemd-cgls 中看到：

• 清晰的kubepods.slice
• QoS 分组 slice
• Pod slice
• Container scope

那么我们可以确定：

✅ 资源隔离可信
✅ QoS 生效
✅ OOM / throttling 行为可预期