容器隔离的核心机制：Linux Namespace 原理与故障排查实战

不知道你们有没有过这种感觉：第一次接触容器时，你觉得它就是个"轻量虚拟机"，体积小、启动快、用起来爽；等踩过几次坑之后，你开始纳闷——为什么容器里的进程 PID 那么小？为什么hostname改一下就只影响容器本身？为什么ifconfig在容器里看到的网卡和宿主机完全不一样？这些问题背后，其实都指向同一个核心机制：Namespace。

我现在做容器平台相关的工作，平时排查问题时，十次有八次最后都会落到 Namespace 上。很多人把 Docker、Kubernetes 挂在嘴边，但对 Namespace 的理解停留在"隔离资源"四个字上，真出了问题就抓瞎。所以这篇博文我想把 Namespace 讲透：它隔离的到底是什么、内核是怎么做到的、容器运行时怎么用它，以及出问题时怎么顺着 Namespace 这条线排查。无论你是刚接触容器的新人，还是已经在生产环境维护集群的工程师，这篇内容应该都能帮你把脑子里那些模糊的碎片串起来，形成一张完整的图。

1. 当我们谈论容器隔离时，到底在隔离什么

1.1 容器不是"轻量虚拟机"

很多人习惯把容器理解成一个"阉割版虚拟机"，这个类比既对又不对。虚拟机通过 Hypervisor 虚拟出一整套硬件，然后在上面跑一个完整的 Guest OS，所以虚拟机里的内核和宿主机内核是两套独立的系统；而容器不是这样，它并没有"虚拟"出一台新机器，它就是宿主机上的普通进程，只是被加了一层"视野限制"。

所谓"视野限制"，就是让一个进程以为自己是系统里唯一的、拥有完整资源的那个进程。比如你启动一个 Nginx 容器，宿主机上其实就多了一个 Nginx master 进程，它和宿主机上的 sshd、cron 一样，共享同一个 Linux 内核。但因为你把它放进了某个 Namespace，它看到的进程表、网络栈、挂载点、主机名等，都和宿主机"看起来"是隔离的。

理解了这个前提，你就能明白为什么容器启动那么快、资源占用那么小：因为它不需要引导内核、不需要初始化系统服务，只是启动几个进程而已。它也没有虚拟机那种"硬件虚拟化层"的开销，性能损耗极低。也正因为如此，容器的隔离强度天然就比不上虚拟机——这是内核机制决定的，不是 Docker 或 Kubernetes 的 bug。

1.2 资源隔离的组成

"资源"这个词听起来宽泛，但在 Linux 内核语境下，它其实可以被拆成几类：进程、网络、文件系统挂载、主机名、进程间通信、用户权限，以及 CPU/内存等计算资源。这里要特别说清楚一个关键点：前六类是由 Namespace 负责的，而 CPU、内存这类计算资源主要由 cgroups（控制组）负责。两者经常被一起提起，因为 Docker 启动一个容器时是同时使用这两套机制的，但它们解决的问题完全不同。

Namespace 管的是"可见性"，解决的是"进程能看到什么"；cgroups 管的是"限额"，解决的是"进程能用多少"。比如你把容器放进一个独立的 PID Namespace 里，容器内就只能看到自己 namespace 内的进程，但它照样能把你宿主机所有 CPU 都吃完，除非你用 cgroups 给它设置 CPU 上限。反过来，你限制了 CPU，但如果不做 namespace 隔离，容器里的进程就能看到宿主机上其他进程的信息，甚至通过ptrace去调试别的进程，非常危险。

所以一个真正"安全"的容器，Namespace 和 cgroups 必须搭配使用。这也是我在面试新人时最喜欢问的问题之一：给你一台 Linux 机器，不用 Docker，你怎么手动做出一套容器隔离？答案就是unshare加上cgroups，下面我会详细展开。

2. Namespace 的前世今生：Linux 内核如何"分身"

2.1 从 chroot 到 namespace

Namespace 的思想其实不是一蹴而就的，它经历了很长的演化过程。最早可以追溯到 Unix 的 chroot，它把进程的根目录限制在一个指定目录里，让进程以为这个目录就是/。但你试试就知道，chroot 只能骗一骗"路径查找"，文件系统里的/proc挂载、网络栈、进程表这些还是全局的。你 chroot 进去之后，依然能看到宿主机上所有进程，依然能用宿主机的网卡，说它是个"监狱"都很勉强。

后来 Linux 内核在 2.4.x 时代引入了 Mount Namespace 的雏形，到了 2.6.24（2008 年）才正式加入 PID Namespace，随后 Network、User 等 Namespace 陆续补齐。整个体系真正被大众熟知，其实要等到 2013 年 Docker 出现。换句话说，Namespace 不是容器时代的发明，而是 Linux 内核长期积累的能力，容器只是把它包装成了一个好用的产品。

我记得自己最早接触 Namespace 是在一次面试被问到"Linux 的 namespace 有哪几种"，当时我只答得上来 PID 和 Network，后面才知道原来一共有 8 种（目前主流的，不含废弃的）。从那以后我养成了一个习惯：看一个容器运行时工具，先去查它默认启用了哪些 namespace，这往往比看 README 更能理解它的设计目标。

2.2 现在 Linux 内核里可以用的 namespace

截至我写这篇文章时，Linux 内核主要提供 8 种 Namespace。为了让你快速建立整体印象，我先列一个表，后面再逐个展开：

另外还有一个已经废弃的 "CLONE_NEWSYSV" 之类，不必过多关注。腾讯、阿里等大厂的内核里可能还有自己加的扩展 namespace，但那是厂商定制，社区主流就是上表这 8 个。

有一个小细节很值得注意：User Namespace 被认为是目前最复杂、也最容易踩坑的一个，很多容器运行时默认不启用它，就是因为它跟挂载、权限、能力（capabilities）交互时经常出幺蛾子。在后面我会专门讲。

3. 六大 Namespace 逐个拆解：原理与实操

3.1 Mount Namespace：容器文件系统的"楚河汉界"

Mount Namespace 是整个容器文件系统隔离的基础。它隔离的其实是"挂载点列表"——每个 namespace 里维护一份独立的挂载信息，进程在这个 namespace 里 mount、umount 时，不会影响到宿主机和其他 namespace。

Docker 之所以能把镜像里的 /etc、/usr、/app 等目录变成容器的根文件系统，靠的就是这套机制。容器启动时，Docker 会先准备一个 rootfs（比如 overlayfs 合并出来的根目录），然后调用类似pivot_root或chroot的操作，把进程的根目录从宿主机的/切换到容器自己的 rootfs，再挂载/proc、/sys等虚拟文件系统到对应位置。

我推荐你做一个实验：在一个运行的容器里 mount 一个临时文件系统，然后回到宿主机看/proc/mounts，你会发现宿主机上完全没有这条挂载记录。反过来，宿主机上挂载一个磁盘，容器里也看不到（除非你显式用-v挂载进去）。这跟我当年用 chroot 做"伪隔离"时遇到的现象完全不同，它才是真正的"视图隔离"。

实际操作中要注意一个坑：挂载传播（mount propagation）会影响 namespace 之间是否能看到新的挂载。Docker 默认给容器挂载卷时用的是rprivate传播模式，也就是"我挂什么你都不知道，你挂什么我也不知道"。这在多数场景下是对的，但在系统级容器里，如果想让容器感知到某些动态挂载，就得调整传播模式，这个后面在故障排查里再细说。

3.2 PID Namespace：为什么容器里进程的 PID 都是 1

PID Namespace 解决的是一道"存在感"问题：容器里的进程以为自己是系统的第一个进程，PID 为 1，看不到其他 namespace 里的进程。有意思的是，PID Namespace 支持嵌套，新 namespace 里进程的 PID 映射到父 namespace 里会变成另一个值。

举个例子：你在宿主机上启动一个容器，容器里 PID 为 1 的进程（比如 bash），在宿主机上看到的 PID 可能是 34621。从宿主机视角看，这个进程并没有"变成"1，它只是被"翻译"成了容器内的 1。这种翻译关系由内核维护，用户态感知不到。

这个机制带来的一个经典现象是"僵尸进程问题"。容器内的 PID 1 进程承担了"孤儿进程收养"的责任，如果容器的主进程不做信号处理、不回收子进程，容器里就会堆积一堆僵尸进程。这也是为什么很多现代容器镜像会选用 tini 这类 init 程序作为入口，而不是直接跑业务二进制——它们在信号转发和僵尸回收上做得更靠谱。我在生产环境里见过不止一次因为忘记处理 SIGTERM 导致容器"杀不死"的例子，根源就在这里。

3.3 Network Namespace：每个容器一张"虚拟网卡"

Network Namespace 隔离的是完整的网络协议栈，包括网卡、回环接口、路由表、iptables 规则等。容器没有独立网卡，Docker 会创建一对 veth 虚拟网卡，一头放进容器 namespace，另一头放在宿主机或者 bridge 上，数据包就这样被"转发"进去了。

你如果进到容器里执行ifconfig或ip addr，会看到只有 eth0 和 lo，看不到宿主机的 eth0、docker0 等设备。这正好解释了为什么容器里的端口 "80" 和宿主机端口 8080 可以互不干扰：它们其实在不同的网络命名空间里，包要通过 iptables 的 DNAT 规则做端口映射才能互通。

我在排查网络问题时，最常用的一招是nsenter -t <pid> -n ip addr，直接进入容器的网络命名空间看它的路由、ARP、连接状态。用ss -tnp看容器内监听端口时，如果发现"明明端口没被占用却报 bind 失败"，多半是因为容器内某个进程已经占用了这个端口，而你在宿主机里看不到——因为它们不在同一个 Network Namespace。

3.4 UTS Namespace：宿主机的 hostname 与容器内的 hostname

UTS Namespace 隔离的是主机名和域名（nodename 和 domainname）。你执行docker run时如果不指定--hostname，容器会拿到一个随机 ID 作为主机名。这就解释了为什么容器里的hostname不会跟宿主机"撞车"。

这个 namespace 的实现非常简单，但它带来的心智模型很重要：容器不是一个真实机器，但通过 UTS Namespace，它可以完美地伪装成一台独立机器。很多应用把主机名写进配置文件或者分布式协调逻辑里，如果没有 UTS 隔离，所有容器都会读到同一个宿主机名，那架构就乱套了。

实际操作中，我一般建议给重要服务显式设置 hostname，别依赖随机 ID。因为日志、监控、注册中心里显示的主机名如果每次都随机，排障时特别痛苦。但要注意，容器内设置的 hostname 只在容器生命周期内有效，容器删除重建后如果没配置好，又会变回去。

3.5 IPC Namespace：把进程通信的"后门"也关掉

IPC Namespace 隔离的是 System V IPC 和 POSIX 消息队列等进程间通信机制。简单说，就是把消息队列、信号量、共享内存这些"跨进程沟通渠道"限制在同一个 namespace 内。

你可能觉得这东西不太重要，但真出过事。我之前遇到过一个诡异问题：一个 Java 应用在容器里跑一段时间后，申请共享内存失败，报错说空间不足。排查到最后发现，它宿主机上残留了大量无人清理的 System V 共享内存段，因为某些历史原因，应用的 IPC 没有被正确隔离，导致它跟宿主机的其他进程共享了同一份 IPC 资源池。后来把应用放进独立 IPC Namespace，问题立刻消失。

这个例子说明：隔离不仅是"安全需要"，也是"可用性需要"。不隔离的资源，终有一天会在你意想不到的地方互相踩踏。

3.6 User Namespace：容器里的 root 与宿主机的 root 不是一回事

User Namespace 是最有权衡意味的 namespace。它允许一个普通用户（非 root）在自己的 namespace 里拥有 root 权限：可以 chown、mount，甚至有些原本需要 CAP_SYS_ADMIN 的操作也能做，但这些权限都被限制在 namespace 内部。

听起来很美好，为什么 Docker 默认不启用？因为它会跟 mount、device cgroup、一些内核接口产生兼容性问题。有些应用会检查 UID 是否为 0，如果容器内是普通用户映射的 root，某些程序会"觉得自己是 root，但干不了 root 的事"，报一些匪夷所思的错误。

在实际生产环境中，我更推荐的做法是"不要依赖 User Namespace，而是用非 root 用户跑容器"，比如镜像里指定USER appuser。这样就算容器被攻破，进程权限也有限。User Namespace 在单机容器（比如 rootless Docker）里很有价值，值得作为一个方案单独研究。

3.7 补充：Cgroup 算不算 Namespace

严格来说，Cgroup 不是 Namespace，但它和 Namespace 一样是 Linux 内核为容器提供的"隔离能力"。Cgroup 负责限制资源使用量：CPU 时间、内存、磁盘 IO、PID 数量等。它和 Namespace 的关系，可以这么理解：Namespace 管"眼界"，Cgroup 管"预算"。

有个容易混淆的 Cgroup Namespace，它其实只是把 cgroup 文件系统路径重新映射了一下，让容器内看到的/sys/fs/cgroup根目录是自己的，而不是宿主机的根。它并不负责资源限制本身。很多人误以为启用了 Cgroup Namespace 就有了"资源隔离"，这是个大错，限制还是得靠 cgroup v2 的控制器配置。

我习惯用一个简单的比喻：Namespace 给每个容器发了一副"独立世界"的眼镜，Cgroup 则给每个容器发了一张"消费额度卡"。眼镜决定你看得见哪些世界，额度卡决定你能花多少钱。两者互相独立，又缺一不可。

4. 真实容器运行时的 Namespace 现场：从 Docker 到 Kubernetes

4.1 docker run 前后发生了什么

要理解容器运行时对 Namespace 的运用，最好的办法是手动模拟一遍。以 Docker 为例，它启动一个容器大致会做这几件事：

• 读取镜像，准备 rootfs（overlayfs 挂载）。
• 调用clone()或unshare()，带上CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWNET ...等标志，创建一个新进程并放进新的 Namespace。
• 在新进程里完成 pivot_root 切换根目录。
• 挂载/proc、/sys、/dev等虚拟文件系统。
• 配置网络（创建 veth、加入 bridge、设置 IP 和路由）。
• 启动容器主进程。

其中clone()那一步是整个事件的核心。内核在创建子进程时，如果设置了对应的CLONE_NEW*标志，就会同时创建出新的 Namespace，子进程自动成为新 Namespace 的成员。你可以在 Linux 上用命令实测：

unshare --fork --pid --mount-proc bash

这条命令会创建一个新的 PID Namespace 和 Mount Namespace，然后在里面挂载一个新的/proc。执行之后，你再执行ps aux，会发现进程表里只有 bash 和 ps，这就是容器内进程视图的最原始雏形。

这正是容器运行时隔离的原理。Docker、containerd、runc 这些工具做得更细致、更完整，但底层思路完全一致。理解了unshare，你就拿到了理解容器的钥匙。

4.2 在宿主机上找到容器对应的 namespace

做容器排障时，经常需要"从宿主机进入容器"或者"查看容器到底用了哪些隔离"。Docker 提供了docker inspect可以查看 namespace 路径，比如：

docker inspect --format '{{.State.Pid}}' my_container

拿到容器主进程的 PID 后，就可以在/proc/<pid>/ns/下看到这个进程所属的各类 namespace：

ls -l /proc/<pid>/ns/

你会看到类似下面的输出：

lrwxrwxrwx 1 root root 0 Apr 1 10:00 ipc -> 'ipc:[4026532287]' lrwxrwxrwx 1 root root 0 Apr 1 10:00 mnt -> 'mnt:[4026532285]' lrwxrwxrwx 1 root root 0 Apr 1 10:00 net -> 'net:[4026532288]' lrwxrwxrwx 1 root root 0 Apr 1 10:00 pid -> 'pid:[4026532286]' lrwxrwxrwx 1 root root 0 Apr 1 10:00 uts -> 'uts:[4026532284]'

每一行的数字402653228x就是 namespace 的唯一标识（inode 号）。如果两个进程的 ipc inode 相同，说明它们共享同一个 IPC Namespace；如果 mnt inode 相同，则共享同一个 Mount Namespace。这个判断方法是我在排查多进程容器问题时最常用的。

比如你怀疑某个进程是不是"混进了"容器里，去看它的 namespace 和容器主进程是否一致，马上就能确认。比docker inspect更直观，尤其在容器已经异常退出、只剩残留进程的时候，这个方法几乎是唯一可靠的判断手段。

4.3 多容器 Pod 里 namespace 怎么共享

Kubernetes 的 Pod 在容器之上又加了一层抽象。一个 Pod 里的多个容器共享同一个 Network Namespace、IPC Namespace 和 UTS Namespace，但默认不共享 PID Namespace 和 Mount Namespace（除非你开启ShareProcessNamespace）。

这意味着 Pod 里的两个容器可以用localhost互相访问，因为它们的网络栈是同一份。这也是为什么 Pod 里的容器不能用同一个端口——它们共享了同一个"端口空间"，一个监听 8080，另一个也想监听 8080，就会冲突。

我经常用一张类比图来理解 Pod 和容器的关系：Pod 是一间房子，容器是住在里面的房客。房客们共享墙壁里的网络管道（Network Namespace）、门牌号（UTS Namespace）和信箱（IPC Namespace），但各自有自己的储物间（Mount Namespace）和证件（PID Namespace）。这个模型能帮你解释很多 Pod 层级的诡异现象，比如"为什么容器 A 里改了 hosts，容器 B 也能看到"——因为它们共享 UTS 和 Network Namespace，/etc/hosts是挂在共享挂载命名空间里的。

如果启用shareProcessNamespace: true，那么 Pod 内所有容器还能看到彼此的进程，PID 空间被打通。这在某些需要容器间信号通信的场景（比如 sidecar 需要给主容器发信号）很有用，但也会削弱隔离性，启用前要评估一下风险。

4.4 容器编排中的 namespace 生命周期

一个常被忽略的点是：Namespace 的生命周期和它内部最后一个进程绑定。只要还有一个进程在 namespace 里，哪怕容器已经"死"了，namespace 依然存在。这会导致一些隐蔽的资源泄漏。

我之前遇到过一个问题：删除了几百个容器，但系统的nsfs文件系统（就是 namespace 的挂载点）占用却迟迟不降，宿主机的 inode 快被耗光了。排查发现是有一些监控脚本为了看容器状态，调用了setns()进入容器的 namespace，但没及时退出，导致 namespace 一直被引用，无法释放。从那以后，我要求所有涉及 namespace 的调试脚本必须加超时和自动退出逻辑，避免把生产环境"拖死"。

在 Kubernetes 环境下，容器重建、Pod 删除时，如果碰到容器被"卡住"（比如D状态进程，拒绝退出），namespace 也不会立刻释放，最终可能积压一大堆 namespace 对象，影响节点健康。这时候最有效的办法是把节点上的 kubelet 容器 GC 和 Pod GC 调好，或者临时手动清掉残留进程。

5. 常见误区与排查技巧实录

5.1 namespace 和 cgroup 的区别，别再混为一谈

这是最常见的误区，我在社区答疑时几乎每周都能看到有人问。一句话总结：Namespace 给人"独立感"，Cgroup 给人"限额"。没有 namespace 的 cgroup 只是"限速器"，没有 cgroup 的 namespace 只是"障眼法"，两者合在一起才是容器隔离的完整形态。

具体到运维场景里，你如果发现一个容器 CPU 使用率飙到 100%，第一反应应该是去查 cgroup 的cpu.max（cgroup v2）或者cpu.cfs_quota_us（cgroup v1），而不是去看 namespace。反过来，如果容器里看不到某个进程，那才轮到 namespace 出场。

我用一个判断技巧：凡是"看见/看不见"的问题，优先怀疑 namespace；凡是"能用多少/能不能用"的问题，优先怀疑 cgroup。这个技巧帮我节省了大量排障时间。

5.2 容器里为什么能看到宿主机进程

容器里看到宿主机进程，这在大部分场景下说明 PID Namespace 没有生效。最典型的原因是 Docker 容器默认是--pid=host共享宿主机 PID 空间，或者你在 Kubernetes 里某个 Pod 的 yaml 里配置了hostPID: true。有些运维同学为了避免 PID 过多导致的问题，会图方便用 hostPID，结果把容器的进程隔离直接放弃了。

另一个隐蔽原因是 PID Namespace 只隔离"进程列表"，但/proc是虚拟文件系统，如果没有在容器内重新挂载一个干净的/proc，容器进程依然可以通过/proc看到宿主机上所有进程的信息。所以启动容器时，容器运行时都会重新 mount/proc，就是为了避免这种"看得到"的泄漏。

我们在自研容器管理平台时，就遇到过因为修改 /proc 挂载参数不当，导致容器内能看到宿主机其他租户进程的情况，安全审计直接被刷屏。最后整改方案就是统一校验容器启动参数里的 namespace 和 /proc 挂载方式，禁止裸奔配置。

5.3 网络 namespace 的排查套路

网络问题大概是容器故障里最让人头痛的一类。我分享几个比较实用的排查步骤：

• 先确认容器主进程 PID：docker inspect -f '{{.State.Pid}}' <name>
• 用nsenter -t <pid> -n进入容器网络命名空间执行ip addr、ip route、ss -tnp。
• 对比宿主机上的 veth 对端和容器内 eth0 的对应关系，排查网线是否"插对口"。
• 检查 iptables / nftables 规则是否把流量转发到了正确的端口。

有一次我们线上服务突然不可达，容器还在跑，端口也在监听，但流量就是进不来。顺着这个路子排查，发现是某个运维脚本在宿主机上做安全策略时，误删了一条 DOCKER 链的 iptables 规则，导致 DNAT 没有生效，外部流量无法转发到容器端口。这种问题如果不进入网络 namespace 去验证实际链路，光看表面现象很容易误判成应用故障。

5.4 用 nsenter 手动进入容器 namespace 调试

nsenter是一个极其实用的工具，它可以让你以宿主机 root 身份，进入任意进程的 namespace 去执行命令。我常用的几条：

# 进入容器的网络命名空间 nsenter -t <pid> -n bash # 进入容器的 PID 命名空间，用 ps 查看容器内进程 nsenter -t <pid> -p ps aux # 同时进入 mount 和 pid 命名空间，模拟容器完整环境 nsenter -t <pid> -m -u -i -p bash

注意顺序：先-t <pid>指定目标进程，然后把带进去的 namespace 一一列出来。如果你想把 pid 和 mount namespace 都带进去，要特别小心——进入了新的 mount namespace 后，根目录可能已经变成容器 rootfs，bash的可执行文件还在不在那个 rootfs 里？如果不在，命令会直接bash: command not found。这时候可以先用-m -p进去，再用绝对路径找系统里的静态工具。

这个工具在容器自愈脚本、故障处理、取证分析里都有大用途。我见过很多资深工程师都在自己的工具箱里放了一个 busybox 静态编译版本，专门用来在 namespace 切换后执行基础命令，因为容器镜像里不一定带ip、ss这类排查工具。

6. 进阶思考：Namespace 之外的边界

6.1 容器安全与 Namespace 的局限

很多安全报告会强调"容器不等于安全沙箱"，核心原因就在于 Namespace 提供的隔离不是 CPU 级别的安全边界。内核里仍有很多全局资源、系统调用和/proc接口并没有被 Namespace 完全隔离，比如dmesg日志、某些内核模块加载状态等，在默认配置下容器内都是可见的。

为了弥补这个问题，业界出现了很多方案：gVisor 在用户态重新实现了一个"应用内核"，Kata Containers 直接跑一个轻量虚拟机，Firecracker 则是为无服务器场景设计的微型 VM。它们本质上都是"既然 Namespace 不够硬，那就换一种隔离方式"。

但我说句公道话：Namespace 的局限不等于它没用。对绝大多数应用场景来说，Namespace 加 cgroups 的隔离强度已经足够，把它当作"纵深防御"的一环，再配合 seccomp、AppArmor、只读根文件系统等措施，安全水位可以提得很高。关键是你得清楚边界在哪，不要盲目依赖单一机制。

6.2 Namespace 的编排：从单机到集群的演变

在单机上，Namespace 是内核为我们提供的一件"法宝"。但到了 Kubernetes 这种集群层面，"隔离"这件事就被抽象成了 Pod、Namespace（注意这里的 namespace 是 K8s 里的逻辑概念，跟 Linux Namespace 不是一回事）、NetworkPolicy 等更高维度的对象。这里容易混淆，我建议大家在文档或者讨论中，把它们区分开，比如管 Linux 的叫"内核 Namespace"，管 K8s 的叫"命名空间"，避免歧义。

最近几年，容器圈开始流行"用户态内核"（如 gVisor）、"微虚拟化"（如 Kata）、"沙箱容器"等概念，它们要解决的仍然是 Namespace 无法彻底解决的安全边界问题。但不管上层怎么演进，底层 Linux 内核提供的 Namespace 依然是理解这些方案的基础坐标。一个不会看/proc/<pid>/ns/的工程师，遇到新老容器运行时都会束手无策；反过来，把 Namespace 吃透了，换什么运行时都只是换一层壳。

我自己的体会是：真正的容器排障能力，不在于你背了多少命令，而在于你理解"进程"在系统里到底是怎么被组织、被隔离、被限制的。Namespace 就是这条主线之一。把它和 cgroup、capabilities、seccomp 串起来理解，你就能在大部分容器问题面前不慌不乱，顺着线索找到根因。这也是我写这篇内容的初衷——希望你在读完以后，再看到"容器"两个字时，脑子里浮现的是一批被精心隔离的进程，而不是一团黑盒。