Linux 内核 Control Groups 与 Namespaces 深度解析：从资源隔离到容器运行时

引言：容器技术的内核基石

Docker、Kubernetes、Podman——这些现代容器技术的背后，是 Linux 内核提供的两大核心机制：控制组（Control Groups，cgroups）和 命名空间（Namespaces）。它们共同构成了容器的隔离与资源控制基础，也是理解 Linux 系统编程、云原生基础设施的关键入口。

本文将从内核实现深度出发，系统解析 cgroups 和 namespaces 的设计哲学、数据结构、工作原理及实际工程应用，涵盖 cgroups v1/v2 的演进、namespace 的 7 种类型、以及它们在容器运行时中的协同机制。

第一部分：Namespaces — 资源视图的隔离

1.1 设计哲学

Linux namespace 的核心思想很简单：全局资源的管理视图隔离。在没有 namespace 的传统 Linux 系统中，所有进程看到的是同一套系统资源——同一组进程 ID、同一个挂载点树、同一个网络接口表。Namespace 机制允许将一组资源打包进一个独立的视图中，使得在该 namespace 内部的进程"以为"自己独占这些资源。

这与 chroot 有本质区别：chroot 仅隔离文件系统根目录，而 namespace 提供的是全方位的系统资源抽象隔离。

1.2 七种 Namespace 类型

Linux 内核自 2.4.19 起逐步引入 namespace 机制，至今已发展出 7 种类型，每种对应一类系统资源的隔离：

最后一种 Time namespace（CLONE_NEWTIME）在 Linux 5.6 引入，允许不同 namespace 设置不同的系统时间——这在需要模拟时间回退的测试场景中非常有用。

1.3 内核实现：数据结构

在内核中，每个进程通过 task_struct->nsproxy 指针关联其所属的 namespace 集合：

struct nsproxy {
    atomic_t count;                 // 引用计数
    struct uts_namespace *uts_ns;    // UTS namespace
    struct ipc_namespace *ipc_ns;    // IPC namespace
    struct mnt_namespace *mnt_ns;    // Mount namespace
    struct pid_namespace *pid_ns;    // PID namespace
    struct net *net_ns;              // Network namespace
    struct cgroup_namespace *cgroup_ns; // Cgroup namespace
    struct time_namespace *time_ns;     // Time namespace (5.6+)
};

当进程调用 clone()、unshare() 或 setns() 并带上 CLONE_NEW* 标志时，内核会创建或切换到一个新的 nsproxy 实例，从而让进程进入不同的命名空间。

1.4 PID Namespace — 进程树的嵌套魔法

PID namespace 是最体现 namespace 层次化设计的一类。与 PID 的分配算法不同，PID namespace 支持嵌套——一个 PID namespace 中可以有子 namespace，形成一棵 namespace 树：

• 每个 PID 在每一层 namespace 中都有一个对应的 PID 编号
• 父 namespace 可以看到子 namespace 的进程，但反过来不行
• 最外层（init）PID namespace 是根，PID 1 的进程负责"收养"孤儿进程
• 每个 PID namespace 可以独立分配自己的 PID 1，成为该 namespace 内所有进程的祖先

这也是容器内 systemd 或任意进程可以作为 PID 1 运行的根本原因——在自己的 PID namespace 中它就是"init"。

1.5 User Namespace — 权限映射的关键

User namespace 是实现"容器内 root 容器外非安全模型的核心。它支持 UID/GID 映射：容器内部的 UID 0（root）可以被映射到宿主机的一个非特权的 UID（如 UID 100000）。

# /proc/<pid>/uid_map 示例
0       100000    65536

这意味着容器内的 UID 0 对应宿主机的 UID 100000，容器内 0~65535 映射为宿主机 100000~165535。容器内的"root"实际上在宿主机上只是普通用户，从而实现了权限降级安全。

1.6 Network Namespace — 协议栈的完整复制

Network namespace 是容器网络的基础。创建新的 network namespace 时，内核在该 namespace 中初始化一套完整的协议栈状态：

• 独立的 struct net 实例，包含独立的网络设备表、路由表、ARP 表、socket 表
• 初始状态下只有 loopback 设备（lo）
• 通过 veth pair、bridge、macvlan 等虚拟网络设备实现跨 namespace 连通
• 每个 namespace 有独立的 iptables/nftables 规则集
• 独立的 /proc/net 和 /sys/class/net

第二部分：Control Groups — 资源使用的边界

2.1 设计哲学

如果说 namespace 解决的是"能看到什么"的问题，那么 cgroup 解决的就是"能用多少"的问题。cgroup 允许将进程分组，并为每个组分配资源限额——CPU、内存、I/O、网络带宽等。

2.2 cgroups v1 架构：多控制器分治

cgroups v1 的设计中，每个资源控制器（controller，也叫 subsystem）独立管理自己的层次结构：

• cpu：CPU 时间片分配（CFS 调度器和 RT 调度器）
• memory：内存使用量限制、OOM 控制
• blkio（更名为 io）：块设备 I/O 带宽限制
• net_cls / net_prio：网络分类和优先级标记
• devices：设备文件（/dev）访问权限控制
• freezer：批量挂起/恢复进程（如容器检查点）
• pids：进程数限制（防止 fork bomb）
• hugetlb：大页内存限制

v1 的主要问题是层次结构不一致：当进程被分配到某个 cgroup 且该 cgroup 位于 cpu 子树的某个路径上时，它也可能同时在 memory 子树的不同路径上。这种多树结构使得内核在检查进程资源使用时需要遍历多个不一致的 cgroup 树，语义混乱且效率低下。

2.3 cgroups v2 架构：统一层次结构

cgroups v2（从 4.5 开始引入，5.2 起逐步成熟）的核心变化是单一统一的 cgroup 树：

• 所有控制器作用于同一棵 cgroup 树，不再有独立的子树
• 进程只能位于叶子节点的 cgroup 中（leaf cgroup）
• "No internal processes"原则：非叶子节点不能包含进程
• 资源控制通过 cgroup.controllers 和 cgroup.subtree_control 显式启用
• 始终开启的 pressure stall information（PSI）让内存/CPU/IO 压力监控变得简单高效

v2 的关键配置文件：

# 启用子孙节点的控制器
echo "+cpu +memory +io +pids" > /sys/fs/cgroup/cgroup.subtree_control

# 在子 cgroup 中设置限制
mkdir /sys/fs/cgroup/myapp
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max      # 50% CPU 限制
echo "536870912" > /sys/fs/cgroup/myapp/memory.max          # 512MB 内存限制
echo "524288000" > /sys/fs/cgroup/myapp/memory.high         # 软限制 500MB

2.4 cgroups 与 eBPF 的融合：精细化资源控制

现代 cgroups v2 可以与 eBPF 程序结合，实现更灵活的资源控制策略：

• 通过 cgroup-bpf 类型的 eBPF 程序在 cgroup 层级绑定 BPF 逻辑
• 每个进程加入 cgroup 时触发 BPF 程序，可用于动态调整资源权重
• 配合 BPF_MAP 实现跨 cgroup 的资源使用聚合统计
• 这是 Cilium 等高性能容器网络方案的理论基础之一

第三部分：Namespace + cgroups 的协同——容器运行时的实现原理

3.1 容器创建的全流程

当 docker run -it ubuntu bash 执行时，底层（以 runc 为例）经历了以下步骤：

1. 创建 cgroup：在 cgroups v2 文件系统下创建 /sys/fs/cgroup/<container-id>/，设置 CPU/内存/PID 限制
2. 启动 init 进程：通过 clone3() + CLONE_NEW* 创建包含所有必要 namespace 的进程
3. 配置 namespace：为新进程设置 hostname（UTS）、挂载点（mnt）、网络接口（net）、用户映射（user）
4. 应用 cgroup 限制：将进程 PID 写入 cgroup.procs 文件，启用控制器限制
5. 执行 pivot_root/switch_root：将文件系统的根切换到容器镜像的 rootfs
6. exec 执行用户进程：执行 /bin/bash 或指定的 Entrypoint

3.2 用户态容器运行时架构

现代容器运行时采用 runc → containerd → CRI 的分层架构：

• runc：OCI 规范的参考实现，直接调用内核 API 创建容器（namespace + cgroups）
• containerd：管理容器生命周期、镜像分发、存储和网络
• CRI（Container Runtime Interface）：Kubernetes 与容器运行时交互的标准 gRPC 接口
• Kata Containers / Firecracker：在轻量 VM 中运行容器，用硬件虚拟化替代 namespace 隔离（多租户安全边界）

3.3 rootless 容器：用户空间的全流程隔离

rootless 容器不需要宿主机 root 权限也能运行容器，关键技术包括：

• User namespace 嵌套：将容器 root 映射到子 UID 范围
• newuidmap/newgidmap：映射文件，安全分配宿主机 UID 范围
• pasta/slirp4netns：用户态网络栈，避免内核特权网络操作
• fuse-overlayfs：用户态覆盖文件系统，支持 overlayfs 挂载
• cgroup v2 delegation：通过 cgroup.subtree_control 将子树委派给非 root 用户

第四部分：工程实践与性能考量

4.1 容器资源限制的最佳实践

• Always set memory limit：不设内存限制时，容器可能消耗宿主机所有内存触发 OOM killer，影响系统稳定性
• CPU limits vs requests：K8s 中 limits 是硬上限（超过被 throttle），requests 是调度保证
• memory.high 作为软限制：v2 中优先使用 memory.high（软限制，内核尽量回收）而非 memory.max（硬限制，直接 OOM）
• IOWeight 而非绝对带宽：现代 SSD 上使用 io.weight 比 io.max 更灵活高效

4.2 namespace 性能开销

namespace 本身的开销极小——它主要是内核中的额外一层指针间接引用。真正的性能成本来自：

• Network namespace：额外的虚拟网络设备处理路径，约 2~5% 额外延迟
• PID namespace：PID 号在多 namespace 映射时的额外表查找（纳秒级）
• Mount namespace：内核需要维护独立的挂载点链表
• 总体而言，namespace 相比 VM 隔离的性能损失可忽略不计（<5%）

4.3 cgroups 监控与可观测

cgroups 暴露了丰富的资源使用指标，是容器监控的数据根基：

• cgroup.pressure：PSI（Pressure Stall Information）提供 CPU/内存/IO 三维压力指标
• memory.stat：详细的内存使用分解（cache、rss、swap、kernel 等）
• cpu.stat：CPU 使用时长、throttled 时间
• io.stat：块设备读写 I/O 统计
• Prometheus/cAdvisor 和 Datadog Agent 都直接读取 cgroups 的伪文件系统来获取容器指标

第五部分：前沿演进

5.1 Cgroup v2 的全面普及

Linux 内核 5.14 起，cgroup v1 进入"deprecated"状态。主流发行版（Ubuntu 22.04+、Fedora 31+、Debian 11+）已默认启用 v2。Docker 20.10+ 和 containerd 1.4+ 均支持 cgroup v2。但仍有部分遗留工作负载依赖 v1 的子树委托机制，需要关注兼容性。

5.2 time namespace 与 checkpoint/restore

time namespace（5.6）可与 CRIU（Checkpoint/Restore In Userspace）结合，实现容器的实时迁移。迁移后的容器可以在新的宿主机上保持正确的时间流逝感知，而不需要重置时间敏感的应用状态。

5.3 内核 BPF 对 cgroups 的增强

未来方向是将更多策略逻辑通过 eBPF 注入 cgroup 层次结构：

• 动态 CPU 调度策略（根据 cgroup 中进程行为调整时间片分配）
• 自定义内存回收优先级（在 cgroup 级别实现 LRU 个性化）
• I/O 模式的在线检测和自适应带宽分配

结语

cgroups 和 namespaces 是 Linux 内核最伟大的抽象之一——它们不以任何方式改变进程模型，而是在现有进程模型之上构建了一层"可组合的资源隔离"。从单个容器的资源配额，到 Kubernetes Pod 的多层级 cgroup 树，再到 rootless 容器打破特权边界的创新，都建立在这两项机制之上。

理解 namespace 和 cgroups，不仅是运维工程师的必修课，也是任何希望深入 Linux 系统编程、云原生基础设施开发的工程师的核心素养。在内核持续演进的背景下，namespace 与 cgroups 的边界正在被 eBPF 进一步拓展——未来的容器隔离将更加安全、高效和可编程。

参考：Linux 内核源码（v6.x Documentation/cgroup-v2.txt, kernel/cgroup/）、OCI Runtime Spec、Kubernetes CRI 规范