Linux容器隔离技术全解析

本文深入剖析了Linux容器隔离的核心基石——namespace技术，澄清了它并非Docker专属或等同于容器本身，而是一组灵活、底层的内核隔离机制；通过手写代码调用clone()或使用unshare命令，读者可直观理解PID、UTS、NET和MOUNT等namespace如何协同实现进程、主机名、网络及文件系统视图的精细隔离，并避开常见陷阱（如遗漏--fork导致namespace瞬时崩溃、忽略--mount-proc造成/proc显示错乱、未启用lo致使ping失败、挂载传播失控等），真正掌握从原理到实操的完整链路。

namespace 是什么，不是什么

Linux namespace 不是容器，也不是 Docker 的专属功能。它是一组内核机制，用来把进程看到的系统资源（如 PID、网络、挂载点）隔离开。你写个 C 程序调用 clone() 传 CLONE_NEWPID，就能创建一个新 PID namespace —— 和 Docker 启动一个容器本质没区别，只是少了一层封装。

容易踩的坑：
- 误以为开了 namespace 就自动有“完整隔离”：比如只开 CLONE_NEWNET，但没配路由、没启 systemd-networkd，网络还是不通
- 忽略 init 进程约束：在新 PID namespace 里，pid=1 必须是第一个进程，且不能退出，否则整个 namespace 被内核回收

怎么手动跑一个最小 PID + UTS namespace

不用 Docker，用 unshare 命令就能快速验证。它本质是封装了 clone() 和 sethostname() 等系统调用：

unshare --pid --uts --fork --mount-proc /bin/bash

说明：
- --pid 创建独立 PID namespace，你在里面看到的 ps 只有自己和子进程
- --uts 隔离主机名和域名，进去后执行 hostname newbox 不会影响宿主机
- --fork 很关键：不加的话 unshare 自身会变成 pid=1，退出就崩；加了才 fork 出子 shell 当 init
- --mount-proc 必须跟上：否则 /proc 还是宿主机的，ps 显示错乱

常见错误现象：
- 忘加 --fork → 执行完命令立刻退出，namespace 消失
- 忘加 --mount-proc → ps aux 显示宿主机所有进程

network namespace 为什么 ping 不通

开了 unshare --net /bin/bash，进去了发现 ip link 只有 lo，ping 127.0.0.1 都失败 —— 因为默认只建了 netns，没配任何网络设备，lo 也没启用。

实操步骤：
- 在新 netns 里执行 ip link set dev lo up，先让回环接口活起来
- 如果要连外网，得从宿主机拉一条 veth 对：宿主侧配 IP、开转发、设 NAT；netns 侧配 IP、设默认路由
- 更简单的方式是复用宿主机网络：直接用 unshare --net=/proc/1/ns/net /bin/bash（共享 init 进程的 netns）

性能影响：
- veth 对有微小延迟（通常 - 多个 netns 共享同一张物理网卡时，iptables 规则作用域按 netns 划分，别在宿主机 iptables 里删错了链

mount namespace 和 bind mount 的关系

unshare --mount 创建的是独立挂载命名空间，但它不会自动复制当前挂载树 —— 默认是空的，只有 / 本身。所以你进去后 ls / 可能啥也没有，或者只看到 rootfs 的原始内容。

关键操作：
- 先用 mount --make-private /（在宿主机做）防止挂载事件传播到其他 namespace
- 进去后用 mount --bind /home /home 把需要的目录“透传”进来
- 或者更安全地用 mount --rbind /home /home，递归绑定子目录（含挂载点）

容易被忽略的点：
- --rbind 比 --bind 更常用，尤其当 /home 下有 tmpfs 或其他子挂载时
- 如果宿主机用了 overlayfs 或 btrfs subvolume，bind mount 可能失败，得看 /proc/mounts 确认源路径是否可 bind

今天关于《Linux容器隔离技术全解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！