Linux 命名空间与 Cgroups 深度实战：容器底层隔离机制全解析

2026年10月6日 | 系统编程 | Linux内核 | 容器技术

一、为什么需要容器？从隔离的历史讲起

在容器技术出现之前，操作系统级别的资源隔离是一个长期困扰工程师的难题。传统的虚拟机（VM）通过 Hypervisor 硬件虚拟化实现隔离，但重量级、启动慢、资源开销大。容器的本质是 操作系统级别的虚拟化 —— 让多个用户态进程共享同一个内核，但彼此感知不到对方的存在。

容器的两大基石：

• Namespaces（命名空间）：让进程看到什么（视图隔离）
• Control Groups（控制组）：让进程能用多少（资源限制）

本文将深入底层原理，结合大量实战示例，彻底搞清楚这两大机制的实现细节与工程应用。

二、Linux Namespaces 全景解析

2.1 Namespaces 的本质

Namespaces 并非将资源真正复制多份，而是在内核中为同一份资源创建多个视图。每个进程属于特定的 namespace 组合，只能通过所属 namespace 看到对应的资源。这种 copy-on-view 的设计哲学是 Linux 容器轻量化的核心原因。

在 Linux 内核 6.x 版本中，一共存在 8 种 namespace：

1. PID Namespace —— 进程 ID 隔离
2. Network Namespace —— 网络协议栈隔离
3. Mount Namespace —— 文件系统挂载点隔离
4. UTS Namespace —— 主机名与域名隔离
5. IPC Namespace —— 进程间通信资源隔离
6. User Namespace —— 用户与组 ID 隔离
7. Cgroup Namespace —— cgroup 根目录视图隔离
8. Time Namespace —— 系统时钟隔离（Linux 5.6+）

2.2 核心系统调用：clone()、unshare()、setns()

Namespaces 的操作依赖于三个关键系统调用：

int clone(int (*fn)(void *), void *stack, int flags, void *arg, ...);
int unshare(int flags);             // 将当前进程从共享资源中分离
int setns(int fd, int nstype);      // 让当前进程加入某个已有 namespace

clone() 是最底层接口，通过组合 CLONE_NEW* flags 可以创建新的命名空间并让子进程直接加入。unshare() 允许当前运行中的进程离开共享的 namespace 进入新的。setns() 则是最常用的运维接口，docker exec 底层就是通过它实现容器进入。

三、PID Namespace —— 被隔离的进程世界

3.1 原理揭秘：PID 映射表

每个 PID namespace 都有自己的进程编号空间。最关键的特性是：子 namespace 中的 PID 会被映射到父 namespace 的一个 PID，反之则不行。这个映射关系保存在 /proc/PID/status 的 NSpid 字段中。

# 在容器内部看到的 PID
$ docker run -d --name test nginx
# 在宿主机上查看映射关系
$ cat /proc/$(docker inspect test -f '{{.State.Pid}}')/status | grep NSpid
NSpid:  42  1

这表示容器内的 PID 1（nginx master）在宿主机上的实际 PID 是 42。多层嵌套时为 NSpid: 15 8 1 形式。

3.2 实战：使用 unshare 创建独立的 PID Namespace

# 创建 PID namespace + Mount namespace + fork 一个 shell
$ sudo unshare --pid --fork --mount-proc /bin/bash
# 在这个 namespace 里，当前进程就是 PID 1
$ echo $$
1
$ ps aux  # 什么都看不到！因为 /proc 还没重新挂载
$ mount -t proc proc /proc
$ ps aux

这个例子直观展示了 namespace 的隔离能力：在新 PID namespace 中，/bin/bash 变成了 PID 1，可以看到它是无敌的 —— 没有父进程可以收割孤儿，它自己承担 init 的职责。

3.3 PID 1 的特殊性：孤儿收割与信号传播

在 namespace 内部，PID 1 具有极其特殊的语义：

• 孤儿收割：当父进程先退出，孤儿进程会被内核 redirected 给 PID 1。如果 PID 1 不收割，僵尸堆积将吃掉 pid_max
• 信号默认忽略：SIGTERM 和 SIGINT 对 PID 1 默认不处理（除非显式注册 handler）
• 信号终结条件：只有 PID 1 退出，整个 namespace 才会被销毁

这就是为什么在容器中建议使用 tini 或 dumb-init 作为 PID 1 的原因。

四、Network Namespace —— 独立网络世界的构建

4.1 Network Namespace 包含什么

每个 Network Namespace 拥有完全独立的网络协议栈，包括：

• 独立的 routing tables、iptables rules、socket 缓冲区
• 独立的所有网络设备（eth0、lo 等）
• 独立的 ARP neighbor table、conntrack 条目
• 独立的网络协议统计（/proc/net 下各种文件）

4.2 veth pair：连通两个世界的桥梁

veth（Virtual Ethernet）设备像一根网线，一端在 namespace A，另一端在 namespace B，数据包从一个端进入就从另一个端出来。这是容器网络的基础连接方式。

# 创建两个 network namespace
$ sudo ip netns add ns1
$ sudo ip netns add ns2
# 创建 veth pair
$ sudo ip link add veth1 type veth peer name veth2
# 将两端分配到不同的 namespace
$ sudo ip link set veth1 netns ns1
$ sudo ip link set veth2 netns ns2
# 配置 IP 并启动
$ sudo ip netns exec ns1 ip addr add 10.1.1.1/24 dev veth1
$ sudo ip netns exec ns1 ip link set veth1 up
$ sudo ip netns exec ns1 ip link set lo up
$ sudo ip netns exec ns2 ip addr add 10.1.1.2/24 dev veth2
$ sudo ip netns exec ns2 ip link set veth2 up
$ sudo ip netns exec ns2 ip link set lo up
# 测试连通性
$ sudo ip netns exec ns1 ping 10.1.1.2 -c 3

4.3 复杂拓扑：Linux Bridge + veth 构建容器网络

Docker 默认的 bridge 模式本质上是在宿主机上创建一个 docker0 网桥，所有容器的 veth pair 一端连在容器内，另一端通过 brctl addif 接入 bridge。

# 创建 bridge
$ sudo ip link add br0 type bridge
$ sudo ip link set br0 up
# 添加 veth pair 到 bridge（bridge 端）
$ sudo ip link add veth-br type veth peer name veth-ns
$ sudo ip link set veth-br master br0
# 另一端给 namespace
$ sudo ip link set veth-ns netns ns1
# 为 bridge 配置网段 IP，充当容器网关
$ sudo ip addr add 172.18.0.1/16 dev br0

配合 iptables 的 MASQUERADE 规则和 DNAT port mapping，就能实现完整的容器端口映射功能。

4.4 iptables 规则：容器端口映射是怎么实现的

当你运行 docker run -p 8080:80 时，Docker Engine 会在宿主机的 iptables 中添加如下规则链：

# DOCKER 链中的 DNAT 规则
-A DOCKER -p tcp --dport 8080 -j DNAT --to-destination 172.18.0.2:80
# POSTROUTING 中的 MASQUERADE
-A POSTROUTING -s 172.18.0.0/16 -j MASQUERADE

这就是为什么关闭 iptables 后容器端口映射失效的根本原因。

五、User Namespace —— 权限隔离的终极武器

5.1 为什么需要 User Namespace

当一个容器内的进程以 root（UID 0）运行时，它在宿主机上的身份是什么？如果没有 User Namespace，容器内的 root 就是宿主机的 root，这与 sysadmin 共担模式（co-tenant model）完全相悖。

User Namespace 提供了 UID/GID 映射 能力，使容器内的 root 可以被映射到宿主机的一个非特权 UID。用户在容器内是 root，但在宿主机上只是一个普通用户。

5.2 UID 映射表

映射关系保存在 /proc/PID/uid_map 和 /proc/PID/gid_map 中，格式为：

# 容器内UID  宿主机UID  映射数量
    0         1000         1000

含义：容器内的 UID 0-9999 被映射到宿主机的 UID 1000-10999。容器内的 root（UID 0）实质上是宿主机的 UID 1000。

5.3 实战：非 root 用户创建 User Namespace

# 非特权用户即可创建 User Namespace
$ unshare --user --map-root-user /bin/bash
# 验证映射关系
$ cat /proc/self/uid_map
0       1000          1
$ id
uid=0(root) gid=0(root) groups=0(root)
# 在容器内你是 root，但只拥有当前 namespace 的 CAP_NET_ADMIN 等
$ ping -c 1 8.8.8.8
ping: connect: Operation not permitted

这种设计使得 rootless container 成为可能。Rootless Docker、Podman rootless 模式都依赖于此。

5.4 User Namespace 的嵌套层级

User Namespace 可以嵌套 —— 在 User Namespace 内可以创建子 User Namespace，每次嵌套都会做一层映射翻译。Docker 在用户态就是利用这一点在 rootless 模式下创建完整的容器隔离。

六、Cgroups —— 资源分配的精确控制

6.1 Cgroups v1 vs v2：架构演进

Cgroups 经历了从 v1 到 v2 的重大架构变革：

Linux 6.x 内核中，如果启动时传递 systemd.unified_cgroup_hierarchy=1，则默认使用 cgroups v2。现代容器运行时（Docker 20.10+、containerd 1.4+、Kubernetes 1.25+）均已默认启用 v2。

6.2 Cgroups 核心 Controllers

6.3 实战：使用 cgroups v2 限制资源

cgroups v2 以文件系统方式暴露接口，位于 /sys/fs/cgroup/：

# 创建一个新的 cgroup
$ sudo mkdir /sys/fs/cgroup/demo
# 启用 cpu 和 memory controllers（父级操作）
$ sudo echo '+cpu +memory' > /sys/fs/cgroup/cgroup.subtree_control
# 设置 CPU 限制：最多使用 50% 单核（period=100000us, quota=50000us）
$ sudo echo '50000 100000' > /sys/fs/cgroup/demo/cpu.max
# 设置内存上限：最多 256MB
$ sudo echo '268435456' > /sys/fs/cgroup/demo/memory.max
# 设置内存软限制（尽量回收但不 OOM）
$ sudo echo '2147483648' > /sys/fs/cgroup/demo/memory.high
# 加入进程
$ sudo echo $$ > /sys/fs/cgroup/demo/cgroup.procs

6.4 PSI：精确感知资源压力

cgroups v2 引入了 PSI（Pressure Stall Information），这是理解容器内资源瓶颈的关键指标。

$ cat /sys/fs/cgroup/demo/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

• some：至少有一个任务因该资源停滞的比例
• full：所有非空闲任务同时停滞的比例（更严重）
• avg10/avg60/avg300：10秒/60秒/300秒窗口的指数移动平均

Kubernetes 1.27+ 已将 PSI 指标暴露为 metrics-server 的一部分。

6.5 Docker/Kubernetes 中的 cgroups 映射

容器运行时的 cgroups 路径结构通常是：

/sys/fs/cgroup/system.slice/docker-{containerid}.scope/   # Docker
/sys/fs/cgroup/kubepods/pod{poduid}/{containerid}/         # Kubernetes
/sys/fs/cgroup/user.slice/user-1000/session-{id}/          # rootless

查看 Docker 容器的 CPU 限制：

$ docker run -d --cpus=1.5 --name nginx nginx
$ cat /sys/fs/cgroup/system.slice/docker-$(docker inspect -f '{{.Id}}' nginx).scope/cpu.max
150000 100000

含义：每 100000us 周期内，该容器可使用 150000us 的 CPU 时间，即 1.5 核。

七、容器运行时全链路：从 runc 到 Pod 创建

7.1 OCI Runtime Specification

OCI（Open Container Initiative）定义了容器镜像格式（image-spec）和运行时规范（runtime-spec）。runc 是 OCI runtime-spec 的参考实现，负责通过 Linux Namespaces + Cgroups 创建容器。

一个 OCI spec 的核心字段：

{
  "linux": {
    "namespaces": [
      { "type": "pid" },
      { "type": "network" },
      { "type": "mount" },
      { "type": "uts" },
      { "type": "ipc" },
      { "type": "user" }
    ],
    "uidMappings": [{ "containerID": 0, "hostID": 1000, "size": 65536 }],
    "gidMappings": [{ "containerID": 0, "hostID": 1000, "size": 65536 }],
    "resources": {
      "cpu": { "shares": 1024, "quota": 50000, "period": 100000 },
      "memory": { "limit": 268435456 }
    }
  }
}

7.2 runc 执行流程

1. runc create → clone() 子进程进入新的 namespaces
2. 子进程执行 pivot_root() 切换根文件系统（使用容器镜像的 rootfs）
3. 设置 hostname、挂载 /proc、/sys、/dev 等特殊文件系统
4. 应用 cgroups 资源限制
5. drop capabilities，设置 seccomp profile
6. exec() 容器镜像的 entrypoint 程序

整个过程不使用虚拟机，直接复用宿主机的内核，所以容器启动可以达到 毫秒级。

八、安全加固：不止于 Namespace 隔离

8.1 Linux Capabilities：精细化权限控制

传统 Unix root 太粗暴 —— 要么全能力要么没有。Linux 将 root 能力拆分为 ~40 个细粒度 capability。容器运行时默认只保留一小部分：

# Docker 默认 capabilities
CAP_NET_RAW, CAP_CHOWN, CAP_DAC_OVERRIDE,
CAP_FSETID, CAP_FOWNER, CAP_MKNOD,
CAP_SETGID, CAP_SETUID, CAP_NET_BIND_SERVICE,
CAP_SYS_CHROOT, CAP_SETFCAP

建议生产环境使用 --cap-drop=ALL --cap-add=... 的方式做最小权限配置。

8.2 Seccomp：系统调用白名单

Seccomp（Secure Computing Mode）通过 BPF filter 限制容器可使用的 syscall。Docker 默认的 seccomp profile 禁用了 ~44 个危险 syscall，如：

• keyctl、add_key —— 内核密钥管理
• bpf() —— BPF 程序加载（可能逃逸）
• userfaultfd() —— 甚至可用于利用内核 UAF
• kexec_load() —— 内核热替换

编写自定义 seccomp profile：

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "openat", "close", "exit_group"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

8.3 AppArmor/SELinux：强制访问控制

Namespace 和 Cgroups 解决的是 隔离 问题，MAC 解决的是 访问控制 问题：

• AppArmor：基于路径的访问控制（Ubuntu/Debian 默认）
• SELinux：基于类型强制（RHEL/CentOS 默认）

Docker 默认的 docker-default AppArmor profile 禁止容器内直接访问宿主机的 /proc/sys/kernel/*、/sys/devices/** 等路径。

8.4 多层安全纵深

安全的容器运行时需要多层防护：用户 Namespace → Capabilities → Seccomp → MAC → Namespaces+Cgroups，层层叠加，最终保护业务代码。Linux 内核正在从"anything root can do"快速转向"least privilege everywhere"的容器友好形态。

九、生产实践常见问题与调优

9.1 OOM Killer 与容器内存限制的博弈

容器设置了 memory.max=256MB 后，第 256MB+1 字节触发 OOM。但 cgroup OOM 的行为与全局 OOM 不同：

• cgroup OOM 只会杀死该 cgroup 内的进程
• 宿主机内存压力过大时，即便 cgroup 没超也会发生全局 OOM
• oom_score_adj 可用于微调各进程的 OOM 优先级

推荐设置 memory.high 作为软限，让内核在触发强制限制前先行启动内存回收，避免用户态突然 OOM。

9.2 CPU Throttling 与 cpu.max 调优

容器的 CPU 限制在 v2 中使用 cpu.max="$quota $period"，默认 period 为 100000us (100ms)。设置过小的 period（如 1000us）会导致频繁节流。

当容器内多个线程争抢同一个 cpu.max 配额时，可能出现 noisy neighbor 问题——一个 CPU 密集线程占满配额导致其他线程被 throttle。

9.3 PID Namespace 嵌套与 Kubernetes

在 Kubernetes Pod 中，pause 容器承担 Pod 内所有容器共享的 Network/IPC Namespace init 容器。如果 pause 容器 OOM 死掉，整个 Pod 的 Network Namespace 将被销毁，Pod 内所有容器的网络立即断开。

9.4 Rootless 容器的权限陷阱

rootless 模式下 User Namespace 映射了 UID，导致：

• 宿主机文件权限问题：容器创建的文件的 UID 是 1000+N，在宿主机上是其他用户的文件
• CAP_SYS_ADMIN 缺失：无法在容器内 mount、创建设备节点
• 网络限制：默认只能使用 slirp4userpace 而非桥接

解决 UID 映射文件的权限问题：工具可以在宿主机 root 模式和用户模式间做 ID 转换。

9.5 调试工具箱

十、前沿趋势与展望

10.1 Cgroups v2 的全面普及

2024-2026 年间，随着 systemd v250+、Kubernetes 1.25+ 的默认升级，cgroups v2 已成为绝对主流。关键领域的 controller 逐步成熟：

• cpuset v2：NUMA-aware 的 CPU 绑定
• io.cost：基于代价（而非带宽）的 I/O 控制
• misc controller：细粒度资源限制（GPU 显存、RDMA 等）

10.2 多 Namespace 组合应用

10.3 与新内核特性的融合

• Landlock（Linux 5.13+）：非特权沙箱的文件访问控制
• io_uring + io_uring_restriction：限制 io_uring 可使用 opcodes
• Namespace 内 BPF：网络 namespace 内独立 XDP 程序

Linux 内核正在从"anything root can do"快速转向"least privilege everywhere"的容器友好形态。Namespace 和 Cgroups 作为这一转变的两大支柱，将持续演进并成为下一代安全基础设施的基石。

总结

本文从内核视角全面解析了 Linux Namespaces 和 Cgroups 的底层机制与工程实践：

• Namespaces 解决"看到什么"的视图隔离问题，8 种 namespace 组成了容器的骨架
• Cgroups 解决"能用多少"的资源限制问题，v2 版本统一了管控模型
• 二者结合 runc 等运行时构建了轻量级、高密度的容器虚拟化
• 配合 Capabilities、Seccomp、MAC 形成纵深安全体系
• 理解底层原理是排查容器异常、优化资源效率的必备技能

掌握这些知识，不仅能写出更健壮的容器化应用，更能从容面对生产环境中千奇百怪的隔离与资源问题。