容器与命名空间：现代操作系统隔离机制

“容器是轻量级虚拟机”——这句话你大概听过无数次，但它其实是个会误导人的比喻。虚拟机是实打实地模拟了一整套硬件、跑了一个完整的客户机内核；而容器里那个看起来独立的"系统"，根本没有自己的内核，它和宿主机、和旁边的其他容器，共用同一个 Linux 内核。

那它凭什么看起来像一台独立的机器——有自己的进程树、自己的网卡、自己的文件系统、自己的主机名？答案不在虚拟化，而在于 Linux 内核早就提供的两组隔离能力：命名空间（namespace） 和 控制组（cgroup）。容器只是把这些内核原语巧妙地组合起来，包装成了好用的产品。

所以这一篇我们绕开"容器是什么"的表层，先把支撑容器的内核机制讲透——namespace 怎么让进程看到不同的世界、cgroup 怎么限制进程能用多少资源、镜像和联合文件系统怎么实现"独立文件系统"——再回过头讲为什么这套"共享内核 + 视图隔离"的方案能取代笨重的虚拟机。

先抓住一句话：容器 = namespace（看到什么）+ cgroup（能用多少）+ 文件系统镜像（基于什么环境）。 拆开这三样，容器就不再神秘。

一、先想清楚：隔离到底要隔离什么

要让一个进程"以为自己独占一台机器"，得让它在几个维度上都和别人隔开。我们先列出一台机器上有哪些"全局资源"是进程能感知到的：

  • 进程列表：ps 能看到的所有进程、PID 编号；
  • 网络：网卡、IP、端口、路由表；
  • 文件系统挂载点：根目录 /、各种挂载；
  • 主机名：hostname；
  • 用户和权限：UID/GID 体系；
  • 进程间通信：共享内存、信号量等 IPC 对象。

真正的隔离，不是给每个容器一台物理机，而是让每个容器进程看到的上面这些全局资源是"属于自己的那一份"。换句话说，隔离的核心是改变进程对系统资源的"视图"，而不是真的复制一套硬件。

这正是 namespace 干的事——它把上面这些原本全局唯一的资源，虚拟成可以有多份的、彼此隔离的视图。

二、namespace：让进程看到不同的世界

命名空间（namespace） 是 Linux 内核提供的隔离机制。它的核心思想是：把某一类全局资源包装成多个独立实例，让属于不同命名空间的进程看到不同的实例，从而彼此看不见对方。Linux 主要有六（七）种 namespace，每种隔离一个维度：

  • PID namespace：隔离进程号。容器里的第一个进程 PID 是 1，它看不到宿主机的进程，也看不到其他容器的进程。宿主机却能看到所有容器进程（只是 PID 不同）；
  • Network namespace：隔离网络。每个容器有自己独立的网卡、IP、端口空间、路由表。这就是为什么两个容器都能监听 80 端口而不冲突——它们的"80 端口"在不同的网络命名空间里；
  • Mount namespace：隔离文件系统挂载点。容器有自己的根目录和挂载视图，看不到宿主机的目录结构；
  • UTS namespace：隔离主机名和域名。容器能有自己的 hostname；
  • IPC namespace：隔离进程间通信对象（共享内存、消息队列等）；
  • User namespace：隔离 UID/GID。容器里的 root（UID 0）可以映射成宿主机上的一个普通非特权用户——这是容器安全的重要一环。

一句话理解 namespace：它不限制你能用多少资源，只决定你"能看见哪些资源"。 同一台机器上的进程，因为处在不同的命名空间里，就像住在各自独立的房间里，互相看不到对方的存在。

机制上，namespace 是怎么生效的？当用 clone() 系统调用创建进程时，传入特定的标志（如 CLONE_NEWPID、CLONE_NEWNET），内核就会为这个新进程创建对应的新命名空间。之后这个进程及其子进程，看到的就是这套独立视图。容器运行时（如 runc）启动容器，本质就是带着这一堆 CLONE_NEW* 标志去创建进程。

三、cgroup：限制进程能用多少资源

namespace 解决了"看见什么"，但还有个问题它管不了：一个容器疯狂吃 CPU 和内存，会不会把整台机器拖垮、把别的容器饿死？ 光隔离视图不够，还得限制用量。这就是 cgroup（control group，控制组） 的职责。

cgroup 把一组进程组织起来，对它们的资源使用进行限制、统计和隔离：

  • CPU：限制一组进程最多用多少 CPU 时间（如"最多 0.5 个核"）、设置相对权重；
  • 内存：限制最大内存用量，超了就触发回收，再超就被 OOM Killer 杀掉；
  • I/O：限制磁盘读写带宽和 IOPS；
  • 设备访问、网络带宽等。

namespace 和 cgroup 是容器隔离的两条腿，分工清晰：namespace 管"隔离视图"（你看到的世界是独立的），cgroup 管"资源配额"（你能用的资源是有限的）。 缺了 cgroup，一个容器的内存泄漏就能拖垮整台宿主机和所有邻居。

这正是为什么你 docker run 时能加 --memory=512m --cpus=1.5 ——这些参数最终都落到 cgroup 的配置上。Kubernetes 里 Pod 的 requests 和 limits 也是靠 cgroup 落地的。

四、镜像与联合文件系统：容器的"独立文件系统"从哪来

容器还需要一个独立的文件系统环境——它得有自己的 /bin、/lib、应用文件，而不是直接用宿主机的。这靠两样东西实现：镜像（image） 和 联合文件系统（union filesystem，如 overlayfs）。

镜像的精妙之处在于分层（layered）：

  • 一个镜像由多个只读层叠加而成。比如最底层是基础系统（如 Debian），上面叠一层装了运行时（如 Python），再叠一层放你的应用代码；
  • 容器启动时，在这些只读层之上再加一个可写层（容器层）；
  • 联合文件系统把这些层"合并"成一个统一的目录视图呈现给容器——容器看到的是一个完整的文件系统，实际上是多层叠出来的；
  • 容器运行时对文件的修改，遵循写时复制（copy-on-write）：要改一个来自只读层的文件，先把它复制到可写层再改，底层镜像始终不变。

这套机制带来两个巨大好处：一是镜像可共享、省空间——一百个容器用同一个基础镜像，底层那些只读层在磁盘上只存一份；二是启动快——启动容器不必复制整个文件系统，只需加一个空的可写层，瞬间完成。这正是容器比虚拟机轻量、启动快几个数量级的关键原因之一。

镜像分层 + 写时复制，让"每个容器都有独立文件系统"这件事，从"每个都拷一份完整系统"变成了"共享只读层、各自只存增量"。这是容器在存储和启动速度上碾压虚拟机的核心。

五、把机制连起来：docker run 背后发生了什么

把三样东西装在一起，看一次容器启动的完整流程：

  1. 准备文件系统：运行时拿到镜像，用 overlayfs 把镜像的只读层叠起来，加一个可写层，组合成容器的根文件系统；
  2. 创建命名空间：调用 clone() 带上一堆 CLONE_NEW* 标志，创建新进程，给它一套独立的 PID、网络、挂载、UTS、IPC、user 命名空间——于是它看到的是一个"独立的世界"；
  3. 配置 cgroup：把这个进程放进一个 cgroup，按 --memory、--cpus 设好资源上限；
  4. 设置根文件系统：用 pivot_root 把容器进程的根切换到第一步准备好的文件系统，让它只能看到镜像里的内容；
  5. 启动应用进程：在这套隔离环境里执行容器的入口程序（ENTRYPOINT），它成为容器内的 PID 1。

看清楚了吗？容器不是一台新机器，而是宿主机上一个被 namespace 隔离了视图、被 cgroup 限制了资源、被 overlayfs 喂了独立文件系统的普通进程。 它和你 ps 里看到的其他进程没有本质区别——宿主机上 ps aux 能看到容器里跑的进程（只是 PID 不同），这是和虚拟机最根本的差异（虚拟机里的进程宿主机完全看不到）。

六、为什么这套方案能取代虚拟机：成本与密度的胜利

机制讲透，回答"为什么"。为什么不直接用虚拟机做隔离，非要发明容器？对比一下两者的成本：

维度 虚拟机 容器
隔离方式 模拟硬件 + 独立客户机内核 共享宿主内核 + namespace/cgroup
启动速度 几十秒（要启动整个 OS） 毫秒到秒级（只是起个进程）
资源开销 每个 VM 占用 GB 级内存、独立内核 极小，接近裸进程
部署密度 一台机器跑几十个 一台机器跑成百上千个
隔离强度 强（硬件级边界） 较弱（共享内核）

容器的设计哲学是：用操作系统已有的隔离原语（namespace + cgroup），换取虚拟机几乎全部的隔离效果，却省掉"为每个实例跑一个完整内核"的巨大开销。 这是一笔在云计算时代极其划算的买卖——它让微服务、CI/CD、弹性伸缩这些现代部署模式在经济上变得可行。

但天下没有免费午餐。共享内核是容器轻量的根源，也是它的安全软肋：所有容器和宿主共用一个内核，一旦内核有漏洞被容器内进程利用（容器逃逸），整台宿主机和上面所有容器都可能沦陷。这就是为什么强隔离场景（如多租户公有云）会用 Kata Containers、gVisor 这类"在容器外再套一层轻量虚拟化/拦截内核调用"的方案——本质是在"轻量"和"强隔离"之间重新找平衡。

七、和后端 / SRE 实践的联系

理解了底层机制，很多容器化的现象和坑就有了根：

  • 看懂资源限制异常：容器被 OOMKilled，是它的内存用量撞了 cgroup 的 memory.limit；容器 CPU 上不去、被"限流"，是撞了 cgroup 的 CPU quota。kubectl describe pod 里的 OOMKilled、CPU throttling 指标都直接对应 cgroup；
  • JVM/Go 在容器里的"看不见限制"问题：老版本 JVM 不识别 cgroup 限制，会按宿主机的总内存/核数来设堆大小和线程数，导致容器内频繁 OOM。理解了"容器共享内核、限制靠 cgroup"，你就明白为什么要用支持 cgroup 感知的运行时版本；
  • 网络排查：容器网络问题（连不通、端口冲突）往往要回到 network namespace——nsenter 进容器的网络命名空间看网卡和路由，是排查利器；
  • 镜像优化：理解分层和写时复制，你就知道为什么要把不常变的层放底下、把应用代码放最上面（提高层缓存命中、减小推送体积），为什么多阶段构建能显著瘦身；
  • 容器安全：知道容器共享内核、user namespace 能把容器 root 映射成宿主普通用户，你就懂了"不要用 root 跑容器"、“开启 user namespace remap”、"用 seccomp/AppArmor 限制系统调用"这些加固手段在防什么。

八、动手做一个小实验：亲眼看 namespace 的隔离

不用 Docker，用 Linux 原生命令就能感受 namespace：

1
2
3
4
5
6
7
8
9
# 用 unshare 创建一个新的 PID + mount namespace，并启动一个 shell
sudo unshare --pid --mount --fork --mount-proc bash

# 在这个新 shell 里看进程列表
ps aux        # 你会发现：这里 bash 就是 PID 1，几乎看不到宿主机的进程！

# 退出后，对比宿主机
exit
ps aux | head # 宿主机能看到成百上千个进程

再做个对照实验，看宿主机如何"穿透"容器：

1
2
3
4
# 启动一个容器
docker run -d --name test nginx
# 在宿主机上找容器内 nginx 的进程
ps aux | grep nginx   # 宿主机能直接看到它！只是 PID 和容器内不同

第一个实验让你亲眼看到 PID namespace 制造的"独立世界"——同一台机器，换个命名空间，看到的进程列表完全不同。第二个实验则戳破了"容器是独立机器"的幻觉——宿主机能直接看到容器进程。这两个对比合起来，"共享内核 + 视图隔离"这八个字就刻进脑子里了。

学习这一部分最容易踩的坑

1. 把容器当成轻量虚拟机

容器没有独立内核，它和宿主共享同一个 Linux 内核，靠 namespace/cgroup 隔离。虚拟机才是模拟硬件 + 独立内核。这个区别决定了容器的轻量和它的安全短板。

2. 混淆 namespace 和 cgroup 的分工

namespace 管"看到什么"（隔离视图），cgroup 管"能用多少"（资源配额）。两者是正交的、缺一不可的两条腿。

3. 以为容器天然安全

共享内核意味着内核漏洞可能导致容器逃逸。容器隔离不等于虚拟机级的强隔离，多租户强安全场景需要额外手段（gVisor、Kata、seccomp 等）。

4. 忽视容器 PID 1 的职责

容器入口进程是 PID 1，要负责回收僵尸进程、转发信号。直接用普通业务进程当 PID 1 可能导致僵尸堆积或信号处理异常，常需 tini 这类 init。

总结

容器不是魔法，而是操作系统已有隔离能力的一次工程化组合。核心要点：

  • 容器与虚拟机的根本区别：容器共享宿主内核，靠内核原语隔离；虚拟机模拟硬件、有独立内核；
  • namespace 隔离视图（PID、网络、挂载、UTS、IPC、user），决定进程"看到什么"，让进程以为自己独占机器；
  • cgroup 限制配额（CPU、内存、I/O），决定进程"能用多少"，防止单个容器拖垮全局；
  • 镜像分层 + 联合文件系统 + 写时复制，让每个容器有独立文件系统的同时共享只读层，带来省空间和秒级启动；
  • 容器 = namespace + cgroup + 文件系统镜像，本质是宿主机上一个被隔离、被限额、被喂了独立根的普通进程；
  • 共享内核是轻量的根源，也是安全软肋——容器逃逸风险让强隔离场景需要 gVisor/Kata 等额外方案。

把"共享内核 + 视图隔离 + 资源限额"这条主线记牢，你再看 K8s 的资源限制、容器 OOM、镜像优化、容器安全加固，会发现它们讲的都是这三样内核机制在不同侧面的体现。

参考资源：