目录

一、CGroups 的核心定位：补全容器资源管理闭环

1. 本质与价值

2. 与 Namespace 的互补关系

二、CGroups 的五大核心能力

1. 资源使用限制（核心）

2. 资源优先级分配

3. 资源使用监控

4. 进程生命周期操作

5. 层次化结构支持

三、CGroups 关键子系统（资源管理模块）

四、CGroups 工作流程：从配置到生效

1. 挂载 CGroups 文件系统

2. 创建控制组

3. 配置资源规则

4. 加入进程到控制组

5. 监控与生效验证

五、CGroups 在 Docker 中的落地应用

1. 自动创建控制组

2. 核心资源限制参数

3. 资源监控

六、CGroups v1 vs v2：版本演进与优化

七、CGroups 的核心价值

1. 稳定性保障：

2. 资源精细化运营：

3. 编排平台支撑：

总结

---

CGroups（Control Groups，控制组）是 Linux 内核提供的进程资源管理核心机制，能够对进程组的 CPU、内存、磁盘 I/O 等系统资源进行精准限制、实时监控和优先级分配。它从底层解决了多进程/容器在同一宿主机的资源争用问题，是 Docker、Kubernetes 等容器技术实现“资源可控”的核心支撑，与 Namespace 共同构成容器“隔离+限制”的完整能力体系。

一、CGroups 的核心定位：补全容器资源管理闭环

1. 本质与价值

CGroups 并非独立软件，而是内核级的资源分组管理框架：将系统进程按业务需求划分到不同“控制组”，为每个组配置资源规则（如内存上限、CPU 占比），内核调度资源时严格遵循这些规则，最终实现“资源按需分配、使用可管可控”。

2. 与 Namespace 的互补关系

技术	核心作用	通俗理解
Namespace	隔离资源视图（如PID、网络）	让容器“看不到”外部资源
CGroups	限制资源使用（如CPU、内存）	让容器“用不了超出限制的资源”

二者协同工作：Namespace 实现容器“环境隔离”，CGroups 实现容器“资源管控”，共同支撑容器的独立运行与稳定调度。

二、CGroups 的五大核心能力

CGroups 围绕“资源全生命周期管理”设计，核心能力覆盖限制、分配、监控、操作、层级化五大维度：

1. 资源使用限制（核心）

为进程组设置资源“硬上限”，超出时内核强制干预：

CPU 限制：限制核心数（如最多使用 1 核）、时间片占比（如多核心环境占 50%）；

内存限制：设置物理内存/交换空间上限，超出触发 OOM（内存耗尽）杀死进程；

磁盘 I/O 限制：管控读写速率（如读速≤100MB/s）、IOPS，避免拖慢磁盘整体性能；

设备访问限制：控制硬件设备（如磁盘、USB）的访问权限（只读/禁止），提升安全性。

2. 资源优先级分配

资源紧张时，高优先级组优先获取资源：

CPU 份额：默认每组 1024 份额，A 组 2048、B 组 1024 时，A 组获 2/3 CPU 时间；

磁盘 I/O 权重：高权重组在磁盘繁忙时优先完成读写。

3. 资源使用监控

通过文件接口暴露实时资源消耗数据，支撑运维监控：

CPU：总耗时、每核使用量（cpuacct.usage）；

内存：当前使用量、峰值（memory.usage_in_bytes）；

磁盘 I/O：读写字节数、IOPS（blkio.io_service_bytes）。

4. 进程生命周期操作

对控制组内进程批量管理：

挂起/恢复：通过 freezer 子系统暂停（FROZEN）或恢复（THAWED）所有进程；

批量终止：删除控制组时自动终止组内进程（需开启 notify_on_release）。

5. 层次化结构支持

支持控制组嵌套形成树状结构，父组限制自动传递给子组：

示例：父组 web-services 限制 CPU 2 核，子组 nginx/tomcat 各限 1 核，子组总资源不超父组；

适配场景：K8s 中“Node → Namespace → Pod”的资源层级管理。

三、CGroups 关键子系统（资源管理模块）

CGroups 按资源类型拆分出独立子系统，每个子系统负责一类资源管理，默认挂载在 /sys/fs/cgroup 目录，通过文件操作即可配置：

子系统	管理资源	核心配置文件	关键作用
cpu	CPU 调度/使用率	cpu.cfs_quota_us、cpu.shares	限制核心数、分配优先级
cpuacct	CPU 使用统计	cpuacct.usage、cpuacct.usage_percpu	监控 CPU 消耗
memory	内存/交换空间	memory.limit_in_bytes、memory.swappiness	限制内存、触发 OOM 保护
blkio	磁盘 I/O	blkio.throttle.read_bps_device、blkio.weight	限制读写速率、分配 I/O 优先级
devices	硬件设备访问	devices.allow、devices.deny	控制设备访问权限
freezer	进程挂起/恢复	freezer.state	批量管控进程状态
net_cls	网络流量分类	net_cls.classid	为数据包打标签，配合 tc 控流量
pids	进程数量	pids.max、pids.current	限制进程总数，防止 fork 炸弹
hugetlb	大页内存	hugetlb.1GB.limit_in_bytes	优化内存密集型应用（如数据库）

四、CGroups 工作流程：从配置到生效

CGroups 基于文件系统实现，核心流程为“挂载→建组→配置→加进程→监控”，全程通过简单的文件操作完成：

1. 挂载 CGroups 文件系统

Linux 启动时自动挂载，每个子系统对应独立目录：

# 查看挂载情况

mount | grep cgroup

# 输出示例：tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

2. 创建控制组

新建文件夹即创建控制组，内核自动生成默认配置文件：

# 在 memory 子系统创建 nginx 控制组

mkdir /sys/fs/cgroup/memory/nginx-group

# 查看配置文件

ls /sys/fs/cgroup/memory/nginx-group

# 输出：memory.limit_in_bytes、memory.usage_in_bytes 等

3. 配置资源规则

写入配置文件即可生效，无需复杂 API：

# 限制 nginx-group 内存上限 512MB（字节数：512*1024*1024=536870912）

echo 536870912 > /sys/fs/cgroup/memory/nginx-group/memory.limit_in_bytes

# 禁止使用交换空间

echo 0 > /sys/fs/cgroup/memory/nginx-group/memory.swappiness

4. 加入进程到控制组

将进程 PID 写入 tasks 文件，进程及子进程均受规则约束：

# 启动 nginx 并获取 PID（假设为 1234）

nginx -g "daemon on;"

# 加入控制组

echo 1234 > /sys/fs/cgroup/memory/nginx-group/tasks

# 验证归属

cat /proc/1234/cgroup | grep memory

# 输出：memory:/nginx-group

5. 监控与生效验证

读取配置文件查看资源使用，超出限制触发内核保护：

# 查看当前内存使用量

cat /sys/fs/cgroup/memory/nginx-group/memory.usage_in_bytes

# 查看 OOM 日志

dmesg | grep -i "out of memory"

五、CGroups 在 Docker 中的落地应用

Docker 完全依赖 CGroups 实现容器资源限制，屏蔽了底层配置复杂度，核心流程如下：

1. 自动创建控制组

启动容器时，Docker 在 /sys/fs/cgroup 各子系统目录下，创建 docker/[容器ID] 命名的控制组，并自动填充配置。

2. 核心资源限制参数

Docker 命令行参数直接映射到 CGroups 配置：

Docker 参数	对应子系统	作用	示例
--memory/--memory-limit	memory	限制内存上限	docker run --memory=512M nginx
--memory-swap	memory	限制内存+交换空间总上限	docker run --memory=512M --memory-swap=1G nginx
--cpus	cpu	限制 CPU 核心数	docker run --cpus=0.5 nginx
--cpu-shares	cpu	设置 CPU 优先级	docker run --cpu-shares=2048 nginx
--device-read-bps	blkio	限制设备读速率	docker run --device-read-bps=/dev/sda:100MB nginx

3. 资源监控

docker stats 命令的数据直接来源于 CGroups 监控文件：

# 实时查看容器资源消耗

docker stats

# 输出：CPU 使用率、内存使用量/上限、网络/磁盘 I/O 等

六、CGroups v1 vs v2：版本演进与优化

CGroups 经历两大版本迭代，v2 解决了 v1 的设计缺陷，成为当前主流：

特性	CGroups v1（2008，内核 2.6.24）	CGroups v2（2016，内核 4.5）
层次结构	子系统独立层级，配置分散	统一层级，所有子系统共享结构
功能设计	子系统功能重叠（如 cpu/cpuacct）	合并重叠子系统，简化配置
资源视图	无统一视图，管理复杂	支持统一资源视图，整体管控
兼容性	兼容旧内核，生态成熟	Docker 20.10+、K8s 1.24+ 默认支持
安全性	权限控制弱	精细化权限管控，防止非授权修改

七、CGroups 的核心价值

1. 稳定性保障：

防止单个容器占用过多资源导致宿主机崩溃，是多容器共享宿主机的“安全锁”；

2. 资源精细化运营：

按业务优先级分配资源，提升利用率、降低硬件成本；

3. 编排平台支撑：

K8s/Docker Swarm 的资源调度（如 resources.limits）最终依赖 CGroups 落地。

总结

CGroups 是 Linux 内核资源管理的核心，通过“子系统+文件系统接口”的极简设计，实现了进程组资源的“限制、监控、调度”。它与 Namespace 共同构成容器技术的两大基石：Namespace 隔离“资源视图”，CGroups 控制“资源使用”。无论是单机 Docker 还是大规模 K8s 集群，CGroups 都是保障资源可控、系统稳定的底层核心，也是理解容器资源管理的必学技术点。