Linux Cgroup v2：统一资源管理与 PSI 压力感知深度实战

3 阅读 0 评论 0 点赞

引言

在 Linux 内核的资源管理体系中，cgroup（control group）是容器技术的基石。从 2013 年 Linux 3.8 引入 cgroup v1 到现在，容器生态已经发生了翻天覆地的变化。然而 cgroup v1 长期存在的层级组织混乱、控制器协作困难、资源分配不一致等问题，终于在 cgroup v2（自 Linux 4.5 起稳定）中得到了根本性解决。自 2021 年 Fedora 31 起，cgroup v2 成为默认配置；如今 Kubernetes 1.25+ 已正式将 cgroup v2 作为 GA 特性支持，这意味着无论你是在管理大规模 Kubernetes 集群，还是构建高性能计算平台，理解 cgroup v2 都已不再是可选项，而是必备技能。

一、Cgroup v2 核心架构：统一层级（Unified Hierarchy）

1.1 v1 的痛点与 v2 的解决方案

cgroup v1 最大的设计缺陷在于多个控制器（cpu、memory、cpuset 等）可以各自构建独立的层级树。这带来三个严重问题：

层级管理复杂：同一进程同时属于多个层级树时，管理员需要手动保证各树之间的一致性，极易出错
控制器协作困难：memory 控制器和 cpu 控制器在不同树中，无法高效联动进行资源分配决策
资源分配不一致：进程在不同树中的位置导致资源限制的实际效果与预期偏离

cgroup v2 引入统一层级（Unified Hierarchy）架构，所有单一层级树上挂载所有控制器，进程只属于树中的一个节点。这种设计的关键优势：

# v1: 多棵树，混乱
/cgroup/cpu/                  /cgroup/memory/
    ├── system.slice/             ├── system.slice/
    │   ├── serviceA              │   └── serviceA (独立配置)
    │   └── serviceB              └── ...
    └── user.slice/

# v2: 一棵树，统一
/sys/fs/cgroup/
    ├── system.slice/
    │   ├── serviceA  ← cpu+memory+io+pid 限制都在这里
    │   └── serviceB
    ├── user.slice/
    └── kubepods.slice/

1.2 统一层级的三个核心原则

原则一：单一层级树。系统中只有一棵 cgroup 树（通常挂载在 /sys/fs/cgroup），所有控制器在这棵树上协同工作。控制器不能再被单独挂载到不同树中（no internal processes 规则确保叶子节点不参与控制器调度）。

原则二：No Internal Processes。只有在叶子节点（没有子 cgroup 的节点）上的进程才能被控制。如果一个 cgroup 有子 cgroup，则该 cgroup 自身不能持有进程（与 v1 最大的行为改变）。这保证了资源统计和限制的清晰边界。

原则三：资源分配自顶向下。父节点的资源限制在子节点之间分配，子节点的总使用量不能超过父节点。这种\"分蛋糕\"模型让资源管理变成了一个递归的约束满足问题。

1.3 进程与 cgroup 的关系

在 v2 中，一个进程只能属于一个 cgroup（在同一层级树中）。这虽然看起来不如 v1 灵活，但通过线程模式（thread mode）可以部分解决：

# 将进程加入 cgroup
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs

# 查看进程当前 cgroup
cat /proc/self/cgroup
# 输出: 0::/myapp   (v2 的 unified 层级统一编号为 0)

# 线程模式：允许将线程而非整个进程组放入叶节点
echo "threaded" > /sys/fs/cgroup/myapp/cgroup.type

二、核心资源控制器详解

2.1 CPU 控制器：权重调度与硬上限

cgroup v2 的 CPU 控制器提供两种限制模式：权重模式（weight）用于按比例分配 CPU 时间，上限模式（max）用于硬性限制 CPU 使用量。

权重分配（cpu.weight）：取值范围 1-10000，默认值 100。权重越高，在 CPU 争用时获得的时间片比例越大。权重在子 cgroup 间分配：

# 创建两个子 cgroup，分配不同权重
mkdir /sys/fs/cgroup/high_priority
mkdir /sys/fs/cgroup/low_priority

# 高优先级 app 获得 80% CPU（权重比 800:200 = 4:1）
echo 800 > /sys/fs/cgroup/high_priority/cpu.weight
echo 267 > /sys/fs/cgroup/low_priority/cpu.weight

# 将对应进程放入
echo $PID_HIGH > /sys/fs/cgroup/high_priority/cgroup.procs
echo $PID_LOW > /sys/fs/cgroup/low_priority/cgroup.procs

硬上限（cpu.max）：格式为 "$MAX $PERIOD"，表示在 PERIOD 微秒周期内最多使用 MAX 微秒 CPU 时间。这是对 v1 的 cpu.cfs_quota_us/period_us 的整合简化：

# 限制该 cgroup 最多使用 2 个 CPU 核心
# 在 100000us (100ms) 周期内最多使用 200000us CPU 时间
echo "200000 100000" > /sys/fs/cgroup/myapp/cpu.max

# 限制最多使用 0.5 核（在 100ms 周期内最多使用 50ms）
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max

# 查看实际使用情况（单位：纳秒）
cat /sys/fs/cgroup/myapp/cpu.stat
# usage_usec 1234567890
# user_usec 1000000000
# system_usec 234567890
# nr_periods 12543
# nr_throttled 8924
# throttled_usec 4500000000

cpu.stat 中的 nr_throttled（被节流次数）和 throttled_usec（总节流时间）是性能调优的关键指标。如果这两个值持续增长，说明 cpu.max 设置过严。

2.2 内存控制器：三层保护体系

cgroup v2 的 memory 控制器提供了 min、low、high、max 四个阈值，构成了完整的三层保护体系：

内存使用量
  ▲
  │  ╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳╳  max（硬上限）→ OOM Killer 触发
  │  ██████████████████████████  high（高水位）→ 开始主动回收
  │  ░░░░░░░░░░░░░░░░░░░░░░░░  low（低水位）→ 温和回收，保护关键 cgroup
  │  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  min（保证保留）→ 内核绝不回收
  └─────────────────────────────► 0

memory.min：保证分配的内存下限。即使系统内存紧张，内核也不会回收该 cgroup 中使用量在 min 以内的页面。用于保护关键服务（如 DB 缓冲池）。
memory.low：尽力而为的低水位保护。当系统内存紧张时，内核优先回收超过 low 水位的 cgroup 中的内存。适合用于保护后台批处理任务的 QoS。
memory.high：高水位标记。当 cgroup 的内存使用量接近 high 值时，内核会触发直接回收（direct reclaim），降低分配速率。这不是硬限制，但能有效平滑内存使用的尖峰。
memory.max：硬限制。尝试分配超过 max 时立即触发 OOM Killer，在 cgroup 内部选择进程杀死（而非全局 OOM）。

# 配置示例：保证 512MB，软上限 1GB，硬上限 1.5GB
echo "536870912" > /sys/fs/cgroup/myapp/memory.min    # 512MB
echo "1073741824" > /sys/fs/cgroup/myapp/memory.high   # 1GB  → 开始回收
echo "1610612736" > /sys/fs/cgroup/myapp/memory.max    # 1.5GB → OOM

# 查看内存统计（关键指标）
cat /sys/fs/cgroup/myapp/memory.stat
# anon 536870912          # 匿名页（堆内存）
# file 134217728          # 文件缓存页
# kernel_stack 16384      # 内核栈内存
# pagetable 8192          # 页表内存
# ...
# oom 0                   # OOM 发生次数
# oom_kill 0              # 被 OOM 杀死的进程数

内核内存控制（memory.slab）：在 v2 中，内核内存（slab、内核栈、页表等）也被纳入统计。当 cgroup 的内核内存增长过多时（例如创建大量 socket 导致 struct sock 暴涨），同样可能被 OOM 杀死。这在容器安全中至关重要——防止内核内存耗尽攻击。

2.3 IO 控制器：权重与带宽双模式

cgroup v2 的 IO 控制器（io）替代了 v1 的 blkio，支持 rbytes/wbytes 带宽限制和 riops/wiops IOPS 限制，同时支持权重模式按比例分配 IO 带宽：

# 按权重分配 IO（默认权重 100）
echo 300 > /sys/fs/cgroup/db/io.weight     # SSD 数据库服务
echo 100 > /sys/fs/cgroup/backup/io.weight  # 备份服务

# 硬限制带宽：字节每秒
echo "8:0 rbps=104857600 wbps=52428800" > /sys/fs/cgroup/tenant_a/io.max
# 8:0 是主设备号:次设备号，可通过 ls -l /dev/sda 获取

# 硬限制 IOPS
echo "8:0 riops=1000 wiops=500" > /sys/fs/cgroup/tenant_b/io.max

# 查看详细统计
cat /sys/fs/cgroup/myapp/io.stat
# 8:0 rbytes=1234567 wbytes=89012 rios=156 wios=89 ...

需要注意，v2 的 io 控制器只对直接 IO（direct IO，绕过页缓存的 IO）和同步 IO有效。对于经过页缓存的缓冲 IO，由于回写（writeback）发生在内核的 flusher 线程中，IO 控制器需要在 v2.6.36+ 内核中配合 cgroup writeback 功能使用。从 Linux 5.0 开始，writeback 已纳入 cgroup v2 管理（通过 io.weight 或 io.max 限制延迟写回）。

2.4 PID 控制器：防止 fork 炸弹

pids 控制器限制 cgroup 内可以创建的进程/线程总数，是容器安全的基础防线：

# 限制 cgroup 最多 100 个进程
echo 100 > /sys/fs/cgroup/myapp/pids.max

# 查看当前使用量
cat /sys/fs/cgroup/myapp/pids.current

# 查看历史峰值
cat /sys/fs/cgroup/myapp/pids.peak

pids.peak 是 v2 新增的统计特性，记录该 cgroup 自创建以来的最大进程数，对容量规划和异常检测非常有价值。

2.5 RDMA 控制器与 misc 控制器

v2 还提供了用于 HPC 场景的 RDMA 控制器（rdma.max），可以在 cgroup 级别限制 RDMA 资源（QP、MR 数量等），防止单个应用独占 RDMA 设备资源。misc 控制器（misc.max）用于控制杂项资源（如 GPU 显存、NVMe 设备等），由驱动注册资源限制器。

三、Pressure Stall Information（PSI）：颠覆性的资源压力感知

cgroup v2 引入的最具革命性的特性之一就是 PSI（Pressure Stall Information）。在此之前，系统管理员判断资源是否紧张只能看\"剩余量\"——有多少空闲内存、多少 CPU 空闲时间。但\"剩余量\"并不能准确反映用户体验：10GB 空闲内存可能完全够用（如果只有 15GB 实际需求），而 5GB 空闲内存可能已经紧张（如果应用正在频繁触发直接回收）。

PSI 的核心理念是：测量因为资源不足而被迫等待（stalled）的时间比例，这才是对用户感知最直接的指标。

# 查看 CPU 压力
cat /sys/fs/cgroup/myapp/cpu.pressure
# some avg10=12.34 avg60=15.67 avg300=18.90 total=123456789
# "some" 表示至少有一个任务在等待 CPU
# avg10/60/300 = 过去 10秒/60秒/300秒内的平均等待百分比

# 查看内存压力
cat /sys/fs/cgroup/myapp/memory.pressure
# some avg10=0.00 avg60=0.00 avg300=0.00 total=0
# full avg10=0.00 avg60=0.00 avg300=0.00 total=0
# "full" = 所有任务都因内存不足而等待（比 some 更严重）

# 查看 IO 压力
cat /sys/fs/cgroup/myapp/io.pressure
# some avg10=45.67 avg60=32.10 avg300=25.43 total=987654321

指标解读：

some：该 cgroup 中至少有一个任务因对应资源而 stalled 的时间百分比
full（仅 memory 和 io）：cgroup 中所有任务同时 stalled 的时间百分比。full=5.00 意味着在过去某个窗口内，该 cgroup 的所有进程有 5% 的时间都在挨饿
avg10/avg60/avg300：过去 10秒/60秒/5分钟窗口内的指数加权移动平均。avg10 反映即时状况，avg300 反映长期趋势

自动弹性伸缩实战：结合 PSI 与监控系统（如 systemd 的 PressureWatch 或自研守护进程），可以实现基于实际感知压力的自动扩容：

#!/bin/bash
# PSI-based autoscaler for a web service
CGROUP="/sys/fs/cgroup/web-service"

while true; do
    # 读取 10 秒平均内存压力
    read_some_avg=$(grep "some" $CGROUP/memory.pressure | awk '{print $2}' | cut -d= -f2)
    read_full_avg=$(grep "full" $CGROUP/memory.pressure | awk '{print $2}' | cut -d= -f2)
    
    if (( $(echo "$read_full_avg > 5.0" | bc -l) )); then
        echo "[ALERT] Memory pressure full avg10=${read_full_avg}%, scaling up..."
        # kubectl scale deployment web-service --replicas=$((replicas + 1))
    fi
    
    sleep 10
done

四、Cgroup v2 在 Kubernetes 中的集成

4.1 Kubernetes Cgroup v2 演进历程（国内首选技术栈适配）

Kubernetes 对 cgroup v2 的支持经历了三个阶段：

K8s 1.22（2021）：引入 cgroup v2 alpha 支持，需要内核 ≥ 5.8 + containerd ≥ 1.4 + runc ≥ 1.0
K8s 1.25（2022）：进阶为 Beta，默认启用，引入 MemoryQoS 等特性
K8s 1.28+（2024）：全面 GA，移除 alpha gate，成为主流生产配置

国内主流容器平台（阿里云 ACK、腾讯云 TKE、华为 CCE）均已在 2024 年完成 v2 适配；信创场景中 openEuler 22.03+、麒麟 V10 SP2 等国产操作系统率先支持，并已在金融、政务等领域落地。

4.2 Pod QoS 映射到 Cgroup v2

K8s 的三种 Pod QoS class 在 v2 中的映射关系：

# BestEffort Pod → 最低权重
/sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podXXX.slice/
  cpu.weight = 1          # 最低 CPU 权重
  memory.min = 0          # 无内存保证

# Burstable Pod → 按 request 比例分配
/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podXXX.slice/
  cpu.weight = 按比例     # 基于 CPU request 计算
  memory.min = request    # request 作为 min 保证
  memory.max = limit     # limit 作为 max 硬限制

# Guaranteed Pod → request == limit
/sys/fs/cgroup/kubepods.slice/kubepods-guaranteed.slice/kubepods-guaranteed-podXXX.slice/
  cpu.weight = 高         # request == limit 所以权重较高
  memory.min = request    # request == limit == memory.min == memory.max

注意 K8s 不会直接修改 cpu.max（除非设置了 CPU limit），而是通过 cpu.weight 进行比例分配。这是 v2 的最佳实践——在生产中避免 CPU 硬限制（CPU throttling），因为它会导致应用延迟抖动和尾延迟恶化。

4.3 OOM 管理与 v2 的优势

在 cgroup v1 中，当容器 OOM 时内核需要在整个系统中选择进程，可能误杀同一个 cgroup 外的关键进程。而在 v2 中：

# cgroup v2 OOM 只杀死 cgroup 内部的进程
# 容器 OOM 不再影响宿主机或其他容器

# 可以通过 memory.oom.group 控制是否整个 cgroup 组一起被杀死
echo 1 > /sys/fs/cgroup/myapp/memory.oom.group
# 启用后，内存超限时整个 cgroup（包括所有子 cgroup）都会被 kill

4.4 cgroup v2 与用户命名空间（User Namespace）的配合

在 v2 中，与用户命名空间的集成更加安全：rootless 容器（以非 root 用户运行）可以使用 v2 的 cgroup 命名空间。Podman、Rootless Docker、Rootless Kubernetes 都依赖这一特性实现无 root 权限的容器隔离：

# rootless 模式下也可以创建 cgroup
$ podman run --rm -it --cpus=1.5 --memory=512m alpine echo "Hello"
# Podman 自动通过 systemd 的 transient unit 创建 cgroup
# 无需 sudo，无需 setuid binary

五、从 v1 迁移到 v2：策略与最佳实践

5.1 迁移前检查清单

# 1. 确认内核支持（Linux 4.5+ 有基础支持，推荐 5.14+）
$ mount | grep cgroup2
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

# 2. 确认所有控制器可用
$ cat /sys/fs/cgroup/cgroup.controllers
cpu io memory pids

# 3. 确认有哪些控制器可以下放给子 cgroup
$ cat /sys/fs/cgroup/cgroup.subtree_control
cpu io memory pids

# 4. 检查是否还有 v1 残留挂载
$ mount | grep cgroup | grep -v cgroup2
# 如果输出为空，说明已完全迁移

5.2 控制器下放（Delegation）模式

v2 中有一个关键概念是控制器下放（delegation）。父 cgroup 必须通过 cgroup.subtree_control 显式声明哪些控制器可以被子 cgroup 使用：

# 根节点默认不放任何控制器给子 cgroup
cat /sys/fs/cgroup/cgroup.subtree_control
# (空)

# 下放 cpu 和 memory 给子 cgroup
echo "+cpu +memory" > /sys/fs/cgroup/cgroup.subtree_control

# 在子 cgroup 中放 pids 给孙 cgroup
echo "+pids" > /sys/fs/cgroup/myapp/cgroup.subtree_control

# 移除下放
echo "-cpu" > /sys/fs/cgroup/cgroup.subtree_control

这种设计在容器运行时中非常实用：containerd / CRI-O 创建 kubepods.slice 时，只下放必要的控制器给 Pod 级别，Pod 内不能再创建额外的 cgroup 层级，防止容器内进程逃逸。

5.3 systemd 集成

systemd 是 cgroup v2 的最佳拍档，它天然使用 cgroup v2 进行服务管理：

# 运行时创建 transient cgroup（最常用）
systemd-run --scope -p CPUQuota=200% -p MemoryMax=2G \
  /usr/bin/myapp

# service 文件配置
[Service]
CPUWeight=800
MemoryMin=512M
MemoryHigh=1G
MemoryMax=2G
IOWeight=300
TasksMax=1000

# 查看服务的 cgroup 树
systemctl status myapp.service
# └─ /system.slice/myapp.service
#    ├── cpu.max: 200000/100000
#    ├── memory.max: 2147483648
#    └── pids.current: 42

5.4 常见陷阱与解决方案

陷阱一：No Internal Processes 导致的容器创建失败。某些旧版 Docker/runc 在 v2 模式下无法正确处理内部进程限制。解决方案是升级到 containerd ≥ 1.6 + runc ≥ 1.1。

陷阱二：CPU throttling 导致的延迟飙升。在 v2 中，即使 cpu.max 设置合理，如果 workload 不均匀，仍可能导致瞬间 throttling。解决方案：短期内使用 cpu.weight 替代硬限制；长期方案使用 cfs burst（kernel 5.14+ 支持 cpu.max.burst）：

# 允许突发：在 100ms 周期内用 200ms CPU 时间，但 burst 预算限制为 50ms/周期
echo "200000 100000 50000" > /sys/fs/cgroup/myapp/cpu.max
# 第三个参数是 burst（仅 5.14+）

陷阱三：v2 内存统计与 v1 的差异。v2 的 memory.current 包含内核内存（slab、栈、页表等），比 v1 的 memory.usage_in_bytes 更大。如果直接套用 v1 的阈值会导致过早触发 OOM。

六、生产环境监控与调优

6.1 关键指标监控体系

基于 Prometheus + cAdvisor + node_exporter 的 cgroup v2 监控方案：


# cAdvisor 指标（已适配 v2）
container_cpu_usage_seconds_total{cpu="total"}    # CPU 累计使用
container_memory_working_set_bytes                 # 内存工作集（v2 特有）
container_memory_rss                               # RSS（v2 包含更全面）
# Prometheus PSI 自定义指标
node_psi_cpu_waiting_seconds                        # CPU 压力（等待比例）
node_psi_memory_waiting_seconds                     # 内存压力
node_psi_io_waiting_seconds                         # IO 压力

6.2 压力告警规则示例

groups:
- name: cgroup_v2_alerts
  rules:
  # 高内存压力告警（cgroup 内所有任务都在挨饿）
  - alert: CgroupHighMemoryPressure
    expr: avg_over_time(node_psi_memory_waiting_seconds[5m]) > 0.1
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Cgroup {{ $labels.path }} 内存压力超过 10%"
  
  # CPU 节流频繁告警
  - alert: CgroupCPUThrottle
    expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.05
    labels:
      severity: warning
    annotations:
      summary: "容器 {{ $labels.name }} 频繁被 CPU 节流"

6.3 性能调优实战

场景一：数据库容器（MySQL/PostgreSQL）：DB 需要稳定的内存和较低的 IO 延迟，推荐使用 memory.min 保护缓冲池，使用 IO weight 保障读写优先级：

# 数据库容器 cgroup 配置示例
echo "838860800" > /sys/fs/cgroup/mysql/memory.min     # 800MB 保证
echo "8:0" > /sys/fs/cgroup/mysql/io.weight             # 默认权重
echo "2000" > /sys/fs/cgroup/mysql/io.latency          # IO 延迟目标（微秒）
echo "50" > /sys/fs/cgroup/mysql/cpu.weight             # 中等权重

场景二：批处理/Spark/Flink：批处理任务需要大量 CPU 但不希望抢占在线服务，使用较低权重 + 内存 high 水位自动限流：

# 批处理 cgroup 配置
echo "25" > /sys/fs/cgroup/batch/cpu.weight             # 低权重 (约 1/4)
echo "7516192768" > /sys/fs/cgroup/batch/memory.high   # 7GB 开始限流
echo "8589934592" > /sys/fs/cgroup/batch/memory.max    # 8GB 硬上限

场景三：Redis/Memcached：内存缓存服务对延迟极度敏感，避免 OOM 至关重要：

# Redis cgroup 配置
echo "4294967296" > /sys/fs/cgroup/redis/memory.max     # 4GB 硬上限
echo "4831838208" > /sys/fs/cgroup/redis/memory.high   # 4.5GB 开始回收
echo "200" > /sys/fs/cgroup/redis/io.weight             # 高 IO 权重（AOF 持久化）

七、安全加固：Cgroup v2 的安全边界

7.1 防止容器内 cgroup 逃逸

在 v2 中，容器内的进程不应该能够创建新的 cgroup 或修改父级 cgroup 的配置。以下措施可以有效防止 cgroup 逃逸：

v2 的用户命名空间集成：rootless 容器无法修改主机 cgroup（因为 namespace 隔离）
cgroup.subtree_control 下放限制：只在容器级别下放必要控制器，容器内无法获取更多权限

AppArmor/SELinux 策略：限制对 /sys/fs/cgroup 的写操作（容器运行时默认启用）

# 检查容器内是否可写（应该不可写）
$ cat /proc/self/mountinfo | grep cgroup
# 输出应包含 ro（只读挂载）
$ ls -la /sys/fs/cgroup/
# ls: cannot open directory '/sys/fs/cgroup/': Read-only file system

7.2 防止内核内存耗尽攻击

在 v1 中，内核内存（socket buffer、页表等）不在任何 cgroup 的统计范围内，攻击者可以通过创建大量 socket 或线程耗尽内核内存。v2 将内核内存纳入统计：

# 查看 cgroup v2 的内核内存统计
cat /sys/fs/cgroup/myapp/memory.stat
# slab 1234567           # slab 分配器内存
# kernel_stack 98765      # 内核栈（每线程约 8-16KB）
# pagetables 54321        # 页表内存（每个映射约 0.5-4KB）
# ...

# 限制内核内存通过 memory.max（包含内核内存）
# 如果内核内存持续上涨被 OOM 杀死，可以检查：
dmesg | grep -i "oom"
# 输出示例: Memory cgroup out of memory: Killed process 12345 (forkbomb)

八、未来展望：Cgroup v2 的演进方向

cgroup v2 仍在持续演进中，正在开发或即将进入主线的重要特性包括：

Cgroup 压力通知（Pressure Notify）：应用程序可以注册当 PSI 超过阈值时被唤醒的 eventfd，实现比轮询更高效的事件驱动压力响应（已在 kernel 5.17+ 中以 pollable pressure 稳定支持）

Cgroup Kill（cgroup.kill）：通过向 cgroup.kill 写入 1，可以一次性杀死 cgroup 中的所有进程（kernel 5.14+），比遍历 pids.current 逐一 kill 更高效、更原子

TKILL 在 cgroup 内的扩展：允许 cgroup 管理员向整个 cgroup 发送信号，简化容器停止和重启流程

# cgroup.kill 用法（kernel 5.14+）
echo 1 > /sys/fs/cgroup/myapp/cgroup.kill
# 立即杀死 cgroup 内所有进程（SIGKILL），并等待它们退出

此外，社区还在讨论的 Cgroup-aware OOM Killer（按 cgroup 计分选择被杀进程）、更细粒度的网络带宽隔离（与 v2 io 控制器的整合）、以及针对异构计算（GPU/NPU）的资源控制器扩展，都有望在未来几个内核版本中落地。在国产化算力场景中，这些演进对信创服务器、DPU 智能网卡的资源隔离管理具有重要意义。

九、总结

Cgroup v2 不仅仅是 cgroup v1 的升级——它是 Linux 资源管理范式的根本性转变。从\"剩余量\"思维转向\"压力感知\"思维，从多树混乱管理到统一层级清晰分配，从被动式阈值告警到主动式 PSI 驱动调度。对于系统管理员、SRE 和平台工程师而言，掌握 cgroup v2 意味着：

更精确的 QoS 保障：通过 weight、min、high、max 的多维控制，实现从尽力而为到严格保证的平滑过渡

更智能的弹性调度：利用 PSI 压力指标构建事件驱动的自动伸缩系统，告别\"看剩余量凭经验\"的粗放模式
更安全的容器隔离：结合用户命名空间和 subtree_control 下放，硬化和简化容器的资源安全边界

更高效的运维体验：systemd 集成、cgroup.kill、io.latency 等开箱即用的特性大幅降低日常运维复杂度

如果你是还在使用 cgroup v1 的 Kubernetes 集群管理员，建议制定迁移计划，逐步切换到 cgroup v2。迁移过程中重点关注 CPU throttling 策略的调整、内存统计口径的统一、以及 PSI 监控体系的搭建——这些是 v2 落地后运维差异最大的三个方面。

点赞(0) 打赏

本文分类：Linux内核
本文标签：cgroup v2 Linux Kubernetes 容器资源管理 PSI 系统内核
浏览次数：3 次浏览
发布日期：2026-10-10 21:52:40
本文链接：https://www.ybb.press/linux-kernel/16684.html

Linux Cgroup v2：统一资源管理与 PSI 压力感知深度实战

引言

一、Cgroup v2 核心架构：统一层级（Unified Hierarchy）

1.1 v1 的痛点与 v2 的解决方案

1.2 统一层级的三个核心原则

1.3 进程与 cgroup 的关系

二、核心资源控制器详解

2.1 CPU 控制器：权重调度与硬上限

2.2 内存控制器：三层保护体系

2.3 IO 控制器：权重与带宽双模式

2.4 PID 控制器：防止 fork 炸弹

2.5 RDMA 控制器与 misc 控制器

三、Pressure Stall Information（PSI）：颠覆性的资源压力感知

四、Cgroup v2 在 Kubernetes 中的集成

4.1 Kubernetes Cgroup v2 演进历程（国内首选技术栈适配）

4.2 Pod QoS 映射到 Cgroup v2

4.3 OOM 管理与 v2 的优势

4.4 cgroup v2 与用户命名空间（User Namespace）的配合

五、从 v1 迁移到 v2：策略与最佳实践

5.1 迁移前检查清单

5.2 控制器下放（Delegation）模式

5.3 systemd 集成

5.4 常见陷阱与解决方案

六、生产环境监控与调优

6.1 关键指标监控体系

6.2 压力告警规则示例

6.3 性能调优实战

七、安全加固：Cgroup v2 的安全边界

7.1 防止容器内 cgroup 逃逸

7.2 防止内核内存耗尽攻击

八、未来展望：Cgroup v2 的演进方向

九、总结

评论列表共有 0 条评论

发表评论取消回复

Linux Cgroup v2：统一资源管理与 PSI 压力感知深度实战

引言

一、Cgroup v2 核心架构：统一层级（Unified Hierarchy）

1.1 v1 的痛点与 v2 的解决方案

1.2 统一层级的三个核心原则

1.3 进程与 cgroup 的关系

二、核心资源控制器详解

2.1 CPU 控制器：权重调度与硬上限

2.2 内存控制器：三层保护体系

2.3 IO 控制器：权重与带宽双模式

2.4 PID 控制器：防止 fork 炸弹

2.5 RDMA 控制器与 misc 控制器

三、Pressure Stall Information（PSI）：颠覆性的资源压力感知

四、Cgroup v2 在 Kubernetes 中的集成

4.1 Kubernetes Cgroup v2 演进历程（国内首选技术栈适配）

4.2 Pod QoS 映射到 Cgroup v2

4.3 OOM 管理与 v2 的优势

4.4 cgroup v2 与用户命名空间（User Namespace）的配合

五、从 v1 迁移到 v2：策略与最佳实践

5.1 迁移前检查清单

5.2 控制器下放（Delegation）模式

5.3 systemd 集成

5.4 常见陷阱与解决方案

六、生产环境监控与调优

6.1 关键指标监控体系

6.2 压力告警规则示例

6.3 性能调优实战

七、安全加固：Cgroup v2 的安全边界

7.1 防止容器内 cgroup 逃逸

7.2 防止内核内存耗尽攻击

八、未来展望：Cgroup v2 的演进方向

九、总结

Linux 内核网络栈深度拆解：从网卡 DMA 到 Socket 收包的全链路透视

Linux内核进程调度器深度实战：从CFS完全公平调度器到EEVDF算法

Linux Cgroup v2：统一资源管理与 PSI 压力感知深度实战

Kubernetes核心架构：从etcd到调度器的深度解析

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复