6.1 容器底层原理——Linux namespace 与 cgroups

预计阅读时间：15 分钟

学习目标

• 理解容器与虚拟机的本质区别：共享内核 vs 独立内核
• 掌握 7 种 Linux namespace 各自隔离的资源及内核版本
• 能用 unshare / ip netns 手动创建 namespace 隔离环境
• 会用 cgroups v2 限制进程的 CPU、内存和 PID 上限
• 理解 OverlayFS 分层存储原理与 CoW 机制
• 了解容器安全边界和经典逃逸场景

核心知识

知识关联

• 前置知识：3.1：Docker 容器入门 Docker 容器入门（容器使用经验）、2.4：进程管理 进程管理（PID namespace 基础）、1.5：文件系统结构 Linux 文件系统结构（OverlayFS 依赖文件系统知识）
• 后续影响：6.2：Kubernetes 入门 Kubernetes 入门（K8s 基于容器运行时编排 Pod）、5.6：SELinux 与 AppArmor SELinux/AppArmor（容器安全加固）
• 配套技术：unshare/nsenter 手动操作 namespace，cgroups v2 通过 systemd 统一管理资源，runc/containerd 是容器运行时的业界标准

原理讲解

为什么容器选择共享内核而非独立内核

容器共享宿主机内核的设计选择源于对"轻量级"的极致追求。虚拟机为每个实例运行完整的 Guest OS 内核，启动需要引导 BIOS、加载内核、初始化系统服务，耗时分钟级，内存开销数百 MB。容器直接复用宿主机内核，通过 namespace 和 cgroups 实现隔离和资源限制，启动只是 fork 一个进程，耗时毫秒级，内存开销几乎为零。这种设计的代价是安全边界较弱——容器与宿主机共享内核，内核漏洞可能导致容器逃逸。但对于大多数场景（微服务、CI/CD、开发环境），容器的轻量级优势远大于安全风险，且可通过 seccomp、AppArmor、rootless 等机制缓解。

为什么要设计 7 种 namespace

7 种 namespace 各自隔离一类全局资源，这种"按资源类型分离"的设计源于 Unix 哲学——每个机制只做一件事并做好。PID namespace 隔离进程编号（容器内 PID 从 1 开始），NET namespace 隔离网络栈（每个容器有独立的 IP、路由表、iptables），MNT namespace 隔离文件系统挂载点（容器有自己的根文件系统），UTS namespace 隔离主机名（容器可以有自己的 hostname），IPC namespace 隔离进程间通信（共享内存、信号量、消息队列），USER namespace 隔离用户和组 ID（容器内 root ≠ 宿主机 root），CGROUP namespace 隔离 cgroups 视图（容器只能看到自己的资源限制）。如果把所有资源混在一个 namespace 里，管理会变得混乱且难以组合——例如你只想隔离网络但不想隔离 PID，按资源类型分离的设计让你可以自由组合。

OverlayFS 为什么能成为容器存储的标准

OverlayFS 的核心优势是"分层合并 + Copy-on-Write"。Docker 镜像由多个只读层组成（每层是上一层的增量），所有层通过 overlay 合并为统一视图。当容器写入文件时，触发 CoW——将文件从 lower 层复制到容器层再修改，lower 层保持不变。这种设计带来两个关键好处：多个容器共享相同的镜像层，节省磁盘空间；镜像拉取时只需下载缺失的层，减少网络传输。相比 AUFS（已废弃）和 Device Mapper（配置复杂），OverlayFS 实现简单、性能优秀、内核原生支持，成为 Docker 和 containerd 的默认存储驱动。

3.1 容器 vs 虚拟机：隔离模型

容器不是"轻量级虚拟机"。虚拟机通过 Hypervisor 硬件虚拟化提供独立 Guest OS 内核，容器则共享宿主机内核，仅通过内核特性实现隔离。

容器本质上是宿主机上的一组受限进程：namespace 提供隔离视图，cgroups 提供资源约束。

3.2 7 种 Namespace 隔离模型

每种 namespace 将一类全局资源包装成独立视图，使进程"以为"自己独占该资源。

3.3 cgroups 层次结构

cgroups（control groups）将进程组织成树形层次，在每个节点上施加资源限制。Linux 内核自 5.x 起主推 cgroups v2，优势：统一层次结构、更干净的接口、原生支持 pressure stall information（PSI）。

3.4 联合文件系统（Union FS）

Docker 镜像采用分层结构，得益于 OverlayFS（overlay2 驱动）。每一层是上一层的增量，所有只读层通过 overlay 合并为统一视图，容器写入时触发 Copy-on-Write（将文件从 lower 复制到容器层再修改）。

# Docker 镜像层示意
# [容器层]        ← 可写（运行时的修改）
# [镜像层 n]      ← 只读（RUN apt-get install）
# [镜像层 ...]    ← 只读
# [镜像层 1]      ← 只读（FROM ubuntu:24.04）
# ──────────────
# overlay2 merge

3.5 OCI 运行时——容器如何被真正启动

Docker 只是容器生态的"上层建筑"。真正创建 namespace、应用 cgroups、运行进程的是底层的 OCI（Open Container Initiative）运行时。主流实现是 runc（Docker 和 containerd 的默认运行时）。一次 docker run 的完整调用链：

docker run nginx:alpine
  └─ docker CLI → Docker daemon (dockerd)
       └─ containerd（管理镜像与容器生命周期）
            └─ containerd-shim（容器进程的父进程，负责转发信号）
                 └─ runc create（真正执行 fork + 创建 namespace/cgroups）
                      └─ /bin/sh -c nginx（容器内的 PID 1）

runc 启动容器的关键操作：读取 OCI bundle（config.json 声明 namespace、capabilities、挂载点），然后调用内核的 clone() 带 CLONE_NEW* 标志创建进程，再应用 cgroups 限制。可以用 runc run 直接体验（需要 root 和一个 OCI bundle）：

# 用 docker 导出最小 rootfs，再用 runc 手动启动（理解底层的最佳方式）
mkdir -p /tmp/runc-test/rootfs
docker export $(docker create busybox) | tar -x -C /tmp/runc-test/rootfs
cd /tmp/runc-test
runc spec          # 生成默认 config.json
runc run mybox
# 进入容器内 shell（/bin/sh），ps 只有自己
/ # ps
# 输出: PID  USER   TIME COMMAND
#       1    root   0:00 /bin/sh

3.6 容器安全边界——隔离不是安全

namespace 提供的是"视图隔离"而非"安全隔离"。容器与宿主机共享内核，攻击面远大于虚拟机。经典逃逸面与防御：

# 一个"看起来正常"的危险容器——千万不要在生产这么做
docker run -d --privileged --cap-add=ALL \
  -v /:/host -v /var/run/docker.sock:/var/run/docker.sock \
  ubuntu sleep 3600
# 攻击者只需一行就能读写宿主机文件系统：
# chroot /host bash

示例代码

示例 1：unshare 创建 PID + UTS namespace

# 创建新的 PID namespace 并挂载隔离的 /proc
sudo unshare --pid --fork --mount-proc /bin/bash

# 在新的 namespace 中
echo $$
# 输出: 1

ps aux
# 输出: 只显示当前 namespace 的进程

示例 2：ip netns 创建网络 namespace + veth pair

# 创建两个网络 namespace
sudo ip netns add ns1
sudo ip netns add ns2

# 创建 veth pair 并连接到 bridge
sudo ip link add veth1 type veth peer name veth1-br
sudo ip link set veth1 netns ns1
sudo ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth1
sudo ip netns exec ns1 ip link set veth1 up

sudo ip link add veth2 type veth peer name veth2-br
sudo ip link set veth2 netns ns2
sudo ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth2
sudo ip netns exec ns2 ip link set veth2 up

# 测试连通
sudo ip netns exec ns1 ping -c 2 10.0.0.2
# 输出: 2 packets transmitted, 2 received

示例 3：nsenter 进入已有 namespace

# 查看目标进程的 namespace inode
ls -la /proc/$PID/ns/
# 输出: lrwxrwxrwx  ... net -> net:[4026531992]

# 进入目标进程的网络 namespace
sudo nsenter -t $PID -n ip addr

# 同时进入多个 namespace
sudo nsenter -t $PID --pid --mount --net /bin/bash

示例 4：cgroups v2 手动限制内存

# 创建子 cgroup
sudo mkdir /sys/fs/cgroup/myapp

# 限制内存 100MB
echo "100M" | sudo tee /sys/fs/cgroup/myapp/memory.max

# 限制 CPU 50%（50000/100000）
echo "50000 100000" | sudo tee /sys/fs/cgroup/myapp/cpu.max

# 将当前进程加入 cgroup
echo $$ | sudo tee /sys/fs/cgroup/myapp/cgroup.procs

# 验证当前内存用量
cat /sys/fs/cgroup/myapp/memory.current
# 输出: 4194304  （约 4MB）

# 清理
sudo rmdir /sys/fs/cgroup/myapp

示例 5：手动搭建 overlay2 文件系统

# 准备目录结构
mkdir -p /tmp/overlay-test/{lower,upper,work,merged}
echo "lower file" > /tmp/overlay-test/lower/hello.txt

# 挂载 overlay
sudo mount -t overlay overlay \
  -o lowerdir=/tmp/overlay-test/lower,\
upperdir=/tmp/overlay-test/upper,\
workdir=/tmp/overlay-test/work \
  /tmp/overlay-test/merged

# 读取合并视图
cat /tmp/overlay-test/merged/hello.txt
# 输出: lower file

# 在合并层写入（CoW 触发，写入 upper）
echo "overwrite" > /tmp/overlay-test/merged/hello.txt
cat /tmp/overlay-test/upper/hello.txt
# 输出: overwrite
# lower 文件保持不变

# 卸载
sudo umount /tmp/overlay-test/merged

示例 6：capabilities 最小授权实验

# 容器默认拥有的 capabilities（对比 root 的全部能力）
docker run --rm alpine sh -c 'capsh --print | grep Current'
# 输出: Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,
#        cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,
#        cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

# 实验：默认容器无法 mount（cap_sys_admin 被移除）
docker run --rm alpine sh -c 'mount -t tmpfs none /mnt'
# 输出: mount: permission denied

# 实验：只给 NET_BIND_SERVICE 时仍能绑定 80 端口
docker run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
  alpine sh -c 'python3 -m http.server 80 & sleep 1; echo started'
# 输出: Serving HTTP on 0.0.0.0 port 80 ...

# 查看进程实际 capabilities（宿主视角）
docker run -d --name cap-test alpine sleep 300
grep CapEff /proc/$(pgrep -f 'sleep 300' | head -1)/status
# 输出: CapEff: 000001ffffffffff
# 用 capsh 解码：capsh --decode=000001ffffffffff
# 输出: 0x000001ffffffffff=cap_chown,cap_dac_override,...（14 个默认 cap）

常见错误

最佳实践

练习题

1. 手动隔离实验：用 unshare --pid --mount --uts --fork --mount-proc 启动一个 shell，修改 hostname，验证 ps aux 只显示两个进程。退出后检查宿主机 hostname 是否被影响。
2. 跨 namespace 通信：创建两个网络 namespace（ns-red 和 ns-blue），分别配置 IP 10.0.1.1/24 和 10.0.1.2/24，用 veth pair 连接到同一个 Linux bridge，验证 ping 互通。
3. cgroups 内存压测：创建一个 memory.max=50M 的 cgroup，将 stress --vm-bytes 80M --vm-keep -m 1 加入该 cgroup，观察 OOM 行为并用 dmesg 查看内核日志。
4. nsenter 调试：启动一个 sleep 300 作为后台容器进程，用 nsenter -t $PID -n 进入其网络 namespace 执行 ip addr，再用 lsns 列出当前系统的所有 namespace。
5. OverlayFS 实验：手动准备 lower/upper/work/merged 目录，在 lower 中放 3 个文件，通过 merged 修改其中 1 个并删除另 1 个，观察 upper 目录的变化，验证 CoW 行为。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

速查表

学习路径：6.1：容器底层原理 容器底层原理（本篇）→ 3.1：Docker 容器入门 Docker 入门 → 5.2：Docker 生产实践 Docker 生产实践 → 6.2：Kubernetes 入门 Kubernetes 入门 → 6.7：GitOps 入门 GitOps。

cgroups v2 运维实践

在生产环境中，cgroups v2 不仅是容器的底层机制，也是系统管理员排查资源问题的核心工具：

# 查看当前进程的 cgroup 状态
cat /proc/self/cgroup   # 输出 cgroup v2 路径

# 查看容器（Docker）的资源限制
cat /sys/fs/cgroup/docker/{容器ID}/cpu.max
cat /sys/fs/cgroup/docker/{容器ID}/memory.max

# 查看系统级 PSI（Pressure Stall Information）
cat /proc/pressure/cpu     # CPU 压力指标
cat /proc/pressure/memory  # 内存压力指标
cat /proc/pressure/io      # I/O 压力指标

# PSI 阈值告警（当 some avg10 > 10 时告警）
# systemd 可配置：
# MemoryPressureThresholdSec=30s
# MemoryPressureWatch=on

延伸阅读