忘掉Docker，用Linux内核命令亲手搭建一个极简容器

你是不是也看过那种让人头皮发麻的技术文章，满屏的术语、复杂的架构图，最后配一句“底层原理极其深奥”？我当年刚开始折腾容器技术的时候，也被 Docker 那一套东西唬得不轻。什么镜像分层、运行时、网络模型，听起来每一层都高不可攀。

直到后来我在一台干净的 Linux 虚拟机上，亲手把 Docker 那一层外壳剥掉，用最原始的内核命令“拼”出了一个能跑ps、能改主机名、能限制 CPU 的微型容器，才恍然大悟：这项被无数人追捧的“高深技术”，核心思想简单到令人发指——就两个词，隔离和限额。

这篇文章我不打算讲 Docker 怎么用，那些文档到处都是。我想带你做一件更有意思的事：忘掉 Docker，回到 Linux 内核本身，用几条命令手动搭建一个极简容器。这个过程会彻底拆掉你对容器技术的神秘感。当你亲眼看到“容器”只是几个内核特性拼装出来的产品时，以后再遇到任何“高深”的新技术，你都会多一个心眼：它的底子，是不是也是个简单的想法？

1. 先别急着敲命令：容器的本质是两个朴素需求

在动手之前，我觉得有必要先聊聊“为什么”。很多人学技术有个习惯，上来就复制粘贴命令，跑通了就觉得自己会了。结果过两周全忘了，换个环境又抓瞎。原因很简单，你只记住了“怎么做”，没理解“为什么这么做”。

1.1 从“搬家和合租”理解容器到底在解决什么问题

想象一个场景：你在一栋写字楼里租了一间办公室。你需要的其实不是整栋楼，而是楼里的一个独立空间。这个空间有墙，别人看不见你在干什么；有门锁，别人进不来；有独立的电表，你用多少电自己付钱。至于楼里的电梯、消防通道、水电主管道，你是和整栋楼共享的。

容器就是干这件事的。一台 Linux 服务器就像那栋写字楼，上面跑着很多应用，这些应用就像一个个租户。问题是，如果没有墙和门锁，租户 A 不小心把走廊堆满垃圾，租户 B 在房间里放了个大功率电器导致整栋楼跳闸，租户 C 甚至能跑到别人房间里翻东西——这在服务器上就叫进程互相干扰和安全问题。

容器技术要解决的，就是给每个“租户”提供两样东西：

• 隔离：让每个应用以为自己独占了一台机器，看不到也碰不到别人的“房间”。
• 限额：就算某个应用发疯了，也只能吃掉自己那份资源，不能拖垮整栋楼。

而这两个需求，Linux 内核早就准备好了对应的原生产品：namespace（命名空间）负责隔离，cgroup（控制组）负责限额。Docker 从头到尾没有发明任何新的内核机制，它只是把这些老掉牙的机制包装成了一个好用的工具。

1.2 为什么“简单思想”会显得高深：三层包装的迷障

既然核心思想这么简单，为什么我们平时看到的容器技术那么复杂？因为 Docker 在“简单思想”外面包了三层糖衣。

第一层是客户端工具。你敲的docker run、docker build、docker compose，这些都是给人类用的交互界面，它们本身不创建容器。第二层是守护进程和运行时。Docker 的 daemon 接收你的指令，再调用containerd、runc这类底层的容器运行时去真正操作内核。第三层是镜像和仓库体系。为了让你能方便地分发和复用应用环境，它又搞出了镜像分层、联合文件系统、仓库 Registry 这一大套东西。

如果你从第一层开始学，当然会觉得高深莫测，因为你在和一大堆“包装纸”打交道。但如果你直接从最里层开始，先搞懂 namespace 和 cgroup，你再看那三层包装，就会觉得它们只是基于这两个内核特性做的工程化扩展。这也是我写这篇文章的初衷：帮你直接扒到最里层，建立对容器技术的“第一性原理”认知。

2. 第一个核心机制：namespace，给进程一场“单机幻觉”

namespace 这个词听起来学术，但它干的事特别直白：让一个进程及其子进程，只能看到某个维度上的“世界一角”。Linux 里有很多种 namespace，每一种都负责隔离一个维度，比如主机名、进程号、挂载点、网络栈等等。

为了让你有体感，我们直接上手操作。下面所有命令都在一台普通的 Linux 虚拟机里执行就行，建议你用普通用户 + sudo，别直接用 root 在物理机上折腾。

2.1 先动手：用 unshare 体验“换了个新机器”

unshare是 util-linux 包里自带的一个命令，它的作用就是创建一个新的 namespace，让指定命令在那个新世界里运行。我们先从最简单的UTS namespace开始，它隔离的是主机名。

打开终端，先看一下当前主机名：

hostname

然后执行：

sudo unshare --uts /bin/bash

这条命令会创建一个新的 UTS namespace，并在里面启动一个 bash。现在你在新的 bash 里，试着改一下主机名：

hostname my-container hostname

神奇的事情发生了：在这个 bash 里，主机名变成了my-container。这时候你再开一个终端窗口，在宿主机的普通 shell 里执行hostname，会发现宿主机的主机名完全没变。

这就是 UTS namespace 的作用：它把“主机名”这个系统全局属性，变成了 namespace 内部的局部属性。你在里面怎么改，都影响不到外面。是不是特别像你在自己房间里重新贴了个门牌号，外面走廊的指示牌纹丝不动？这个思想贯穿所有 namespace 类型：把全局资源包装成局部视图，让进程产生“我独占了一台机器”的幻觉。

2.2 PID namespace：为什么进程号会从 1 开始

UTS namespace 只是热身，真正让人觉得“有点东西”的是PID namespace，它隔离的是进程号。

退出刚才的 bash，重新执行：

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

注意我加了两个参数：--fork是因为有些程序需要 fork 之后才能正确显示新的 PID namespace；--mount-proc会自动挂载一个新的/proc文件系统，让ps命令只显示当前 namespace 里的进程。

现在在这个新 bash 里执行：

ps aux

你会看到，进程列表里出现了两个进程：一个是PID 1的bash（当前 shell），另一个是PID 2的ps命令。那 PID 1 去哪了？系统初始化进程去哪了？你之前开着的那些 ssh、nginx 进程去哪了？

它们还在宿主机上正常运行，但在这个新的 namespace 里，进程号被重新编号了。当前 shell 变成了 PID 1，就好像它是这台“新机器”的初始化进程一样。宿主机上的其他进程在这个 namespace 里是不可见的，就像你在一栋楼里打开监控系统，只能看到自己这个房间的画面，其他房间的监控你是无权访问的。

这里有一个很关键的细节：我们使用了--mount-proc，否则你进入新的 PID namespace 后执行ps，看到的仍然是宿主机的进程列表。因为/proc是一个动态生成的虚拟文件系统，它会反映它所属 mount namespace 的视图。如果不重新挂载，它就会暴露宿主机的信息。这一点在排查容器问题时特别容易踩坑，后面我会再提到。

2.3 mount namespace：让“挂载”成为私事

既然提到了/proc，我们就顺理成章地聊到mount namespace。它隔离的是文件系统的挂载点。

正常情况下，你在宿主机上mount一个 U 盘或者磁盘分区，所有进程都能看到这个挂载。但有了 mount namespace，每个 namespace 可以拥有自己的挂载点列表。你在里面挂载东西，外面的世界完全无感。

这个能力是容器文件系统隔离的基础。一个容器可以把宿主机的某个目录替换成自己的根文件系统，然后在这个“新根”里面挂载各种东西，而不会影响宿主机。

我举个最常见的例子，执行：

sudo unshare --mount /bin/bash mount -t tmpfs none /mnt df -h /mnt

这里我们把一个临时文件系统（tmpfs）挂载到了/mnt。在这个新 bash 里，/mnt是一个全新的内存盘。但在宿主机的终端里执行df -h /mnt，你会发现宿主机上的/mnt还是老样子，什么都没变。

这就是为什么容器里可以有自己独立的/etc/hosts、/etc/resolv.conf文件，而不污染宿主机。容器启动时，运行时系统会在 mount namespace 里做各种挂载操作，这些操作被 namespace 这堵墙挡在了里面。

2.4 六类 namespace 速查表：它们各管哪一摊事

我们刚才实际接触了 UTS、PID、mount 三种 namespace。Linux 里还有另外几种，为了让你在交流时不露怯，我把它们整理成一张速查表。

这里我想特别强调一个容易误解的点：namespace 提供的是视角隔离，不是安全隔离。它好比是给你一个只能看到单间内部的摄像头，但不代表这个房间就是一堵密不透风的墙。在现代容器实践中，安全隔离还需要配合其他内核机制，比如 seccomp、AppArmor、SELinux 等。所以如果你在面试里被问到“容器安全吗”，正确的回答思路应该是：容器默认有隔离性，但它不是一台真正的虚拟机，安全边界要弱得多。这一点我在后面的“常见问题”部分还会展开讲。

3. 第二个核心机制：cgroup，给进程一套“资源配额”

namespace 解决了“看不见”的问题，但光“看不见”还不够。试想一个场景：一栋写字楼里，每个房间都有墙，互相看不见，但所有房间共用一个总电闸。某个房间用了个超大功率设备，整栋楼跳闸了，其他房间全黑。在服务器上，这就对应着一个进程吃满 CPU、占光内存，导致其他服务卡死甚至宕机。

cgroup（Control Groups，控制组）就是用来解决这个问题的。它的思想更朴素：给进程分组，然后限制每个组的资源用量。

3.1 没有配额时的“吵闹邻居”问题

在云服务时代，“吵闹邻居”是个很经典的运维头痛问题。想象你在一个多租户的物理机上跑业务，隔壁租户的业务突然流量暴涨，疯狂消耗 CPU。如果没有任何配额机制，你这边业务的响应时间就会急剧恶化，明明自己什么都没做错，却要跟着遭殃。

cgroup 就是为了避免这种“互相拖累”而生的。它允许管理员为每个进程组设置 CPU、内存、磁盘 I/O、网络带宽等资源的上限。设置之后，就算某个应用写了个死循环疯狂吃 CPU，它最多也只能吃到分配给你的那部分配额，无法越雷池一步。

3.2 手动创建 cgroup 并限制 CPU

我们先来看看 cgroup 在 Linux 里长什么样。在较新的 Linux 系统（几乎所有主流的发行版）上，cgroup v2 是默认的管理方式。它的入口在/sys/fs/cgroup目录。

我们先看一下已有的控制组：

ls /sys/fs/cgroup

你会看到一堆目录，这就是系统自动创建的各种控制组。现在，我们自己创建一个新的控制组，给它起名叫demo：

sudo mkdir /sys/fs/cgroup/demo

创建完成后，你再看一下demo目录，里面会自动生成一堆接口文件，其中最关键的是cpu.max、memory.max、pids.max这几个。它们就是用来设置配额的地方。

我们先把demo组内的 CPU 配额限制为 0.5 个核心，也就是每 100 毫秒周期内最多使用 50 毫秒：

echo "50000 100000" | sudo tee /sys/fs/cgroup/demo/cpu.max

cpu.max文件里第一个数字是配额（quota），第二个数字是周期（period），单位是微秒。50000 100000就代表在 100 毫秒的周期里，这个组的进程最多只能跑 50 毫秒的 CPU 时间，也就是半核。

接着我们来测试一下。先启动一个烧 CPU 的进程，放到后台：

sha256sum /dev/zero &

这个命令会疯狂计算，占满一个 CPU 核心。用echo $!记下它的 PID，然后把这个 PID 写入demo组的cgroup.procs文件，把这个进程“扔进”我们刚建的控制组：

echo <PID> | sudo tee /sys/fs/cgroup/demo/cgroup.procs

如果你想直观看到效果，可以用top命令观察。你会发现刚才还疯狂占用 CPU 的sha256sum进程，CPU 使用率被死死压在 50% 左右。这就是 cgroup 的威力：不需要修改你的代码，不需要重启进程，只需要在系统层面做一个“配额”设置，资源就能被精准控制。

不同系统的 cgroup 版本不一样。ip 老一点的操作系统还在用 cgroup v1，它的 CPU 限制接口是cpu.cfs_quota_us和cpu.cfs_period_us，用法类似，都是“配额/周期”两个值。如果你用的是 CentOS 7 或者 Ubuntu 16 这类老系统，记得去对应路径找这两个文件。

3.3 限制内存和进程数：除了 CPU 还要管住别的

CPU 配额只是第一步，一个不守规矩的进程还会吃内存、疯狂创建子进程。cgroup 对这两种情况也有天然的应对方案。

限制内存很简单，写入memory.max文件即可。我们限制demo组最多使用 256MB 内存：

echo "268435456" | sudo tee /sys/fs/cgroup/demo/memory.max

这个文件的单位是字节，所以 256MB 换算过来就是268435456。当组内所有进程使用的内存加起来超过这个数时，内核就会触发 OOM（Out Of Memory）机制，优先杀掉组里最耗内存的进程。

限制进程数量也很直接，写入pids.max：

echo "64" | sudo tee /sys/fs/cgroup/demo/pids.max

这个限制指的是组内同时存在的进程/线程总数。如果某个应用因为 bug 陷入 fork 炸弹式的疯狂创建进程，当超过 64 个时，后续的创建操作直接失败。这也是很多容器平台设置“最大进程数”的底层原理。

3.4 namespace 和 cgroup 是两码事，但它们天生一对

到这里，你已经掌握了两套核心机制。我把它们放在一起做个对比：

两者是正交的，可以独立使用，也可以组合使用。实际创建容器的过程中，Docker 会先创建一堆 namespace，让进程以为自己在“新机器”上；再把这个进程放进一个专属的 cgroup，确保它的资源使用尽在掌控。

这个组合思路想通了，你就能理解为什么容器那么轻量了。它不像虚拟机那样需要模拟一个完整的硬件设备、运行一个独立的内核，它只是把宿主机的内核资源做了一层“逻辑切分”。容器里的进程本质上还是宿主机内核管理的进程，只是它的视野变小了、资源额度被限制了而已。

4. 把两个思想合起来：手搓一个“极简容器”

现在，我们把前面讲的两块积木拼到一起，动手搓一个能跑命令的微型容器。这个实验没有用到一行 Docker 命令，但做完之后你会发现，你对“容器”的理解会比很多只会docker run的人都深。

4.1 准备一个极简根文件系统

容器一个重要特性是“根文件系统独立”。也就是说，容器里面的/目录下的文件，和宿主机的/不共享。这一步靠 mount namespace 实现，但我们还需要一个“新根”，总不能凭空变出一个操作系统吧。

这里我们引入一个非常常用的工具：BusyBox。它是一个精简版的 UNIX 工具集，把上百个常用命令（ls、cat、sh、ps等）压缩到一两兆字节里，特别适合用来搭建临时根文件系统。

先创建一个目录，然后下载 BusyBox 并解压出最小根文件系统骨架：

mkdir -p /tmp/mini-root cd /tmp/mini-root # 这里你需要先下载 busybox 静态编译版本，放到当前目录 mkdir -p bin sbin etc proc sys dev cp /path/to/busybox ./bin/busybox ./bin/busybox --install ./bin

这一步执行完之后，/tmp/mini-root/bin下就会出现sh、ls、ps等命令的软链接，它们都指向同一个busybox二进制文件。这个“单文件集成”的设计，就是 BusyBox 体积小到离谱的秘诀。

4.2 用 unshare 组合隔离、限额和换根

接着我们把 namespace、cgroup、chroot 三件事一次性做完：

sudo unshare --uts --pid --mount --fork --mount-proc \ --root=/tmp/mini-root \ /bin/sh

这条命令做了四件大事：

• --uts：新主机名隔离。
• --pid --fork --mount-proc：新进程号隔离，并挂载新的/proc。
• --mount：新挂载点隔离，后续挂载不会影响宿主机。
• --root=/tmp/mini-root：把根目录切换到 BusyBox 的根文件系统，这就是容器的“换根”。

执行完，你会进入一个 Shell 提示符，看起来已经和当前 Linux 完全不一样了。你可以试试：

/pwd /bin/hostname my-container ps aux

这个时候你看到的是一个 PID 从 1 开始、主机名随便改、根目录只剩 BusyBox 工具的“新系统”。在这个环境里，如果你不小心删了什么文件，放心，那只会影响/tmp/mini-root下面的文件，对宿主机的根目录毫发无损。

再配合 cgroup 给这个 shell 加资源限制：

# 先另开一个终端，找到上面 shell 的 PID echo <PID> | sudo tee /sys/fs/cgroup/demo/cgroup.procs

现在你手里这个 shell，就是一个拥有独立视图、独立根目录、受限资源的“容器”了。整个过程只用了内核提供的机制，没有任何魔法。

严格来讲这个实验和 Docker 还有差距，生产级容器会用到pivot_root换根、更精细的 namespace 配置、网络桥接等。但核心骨架你已经亲手搭出来了：隔离视图 + 限制资源 + 切换根目录。这三句话，就是容器的本质。

4.3 为什么 Docker 镜像能分层复用：简单的“增量账”

聊完容器的运行原理，我们顺手把镜像的谜底也揭开，它同样藏着一个极其简单的思想。

Docker 镜像之所以看起来“高级”，是因为它支持分层。你写一个 Dockerfile，FROM ubuntu:22.04，然后RUN apt install xxx，最后生成一个镜像。这个镜像不是一个大而全的实体文件，而是一系列“叠加层”。

每一层记录的是“相对于上一层的差异”，而不是完整的操作系统文件。这就好比整理房间，你不需要每次搬家都把所有东西打包一份，你只要保持一个“基础家具清单”，然后在上面追加每次新增的物品记录。同一台宿主机上，如果 100 个容器都基于ubuntu:22.04，那么这 100 个容器共享同一个底层 ubuntu层，只有各自新增的那一层是独立存储的。

这就是为什么你拉一个 600MB 的镜像经常瞬间完成——因为公共层早就被其他镜像下载过了，而且磁盘上只需要存一份。这个设计的思想基础，其实就是“公共部分只存一次，私有部分增量叠加”，和备份软件里的增量备份逻辑如出一辙。一旦你看穿它，再看到表格里的“镜像体积”时，你就知道那只是“新增层”的大小，不是完整操作系统的体积。

5. 实操过程中容易踩的坑与排查思路

按我的经验，你自己动手敲命令做实验，大概率会遇到下面这些问题。我把它们集中列出来，省得你到处翻资料。

5.1 unshare: unshare failed: Operation not permitted

这是最常遇到的一个报错。原因也很简单：创建某些 namespace（尤其是 PID、Network、User namespace）需要特权。如果你没有用sudo，或者你所在的容器环境本身没有开启相应权限，内核就会拒绝你的请求。

排查思路如下：

• 先用sudo执行。
• 确认内核支持，执行grep -E 'namespaces|pid_ns|user_ns' /boot/config-$(uname -r)，看有没有CONFIG_PID_NS=y之类的配置项。
• 如果你本身就在一个 Docker 容器里做这个实验，还需要给容器加--privileged参数，否则容器内无法再创建新的 namespace。

5.2 cgroup v1 和 v2 参数不一样

不同版本的 Linux 发行版，cgroup 接口差异很大。Ubuntu 22.04 之后基本全面使用 v2，文件叫cpu.max、memory.max。CentOS 7、老版本的 Ubuntu 还是 v1，文件叫cpu.cfs_quota_us、cpu.cfs_period_us、memory.limit_in_bytes。

快速判断当前系统用的是 v1 还是 v2：

stat -fc %T /sys/fs/cgroup

输出如果是cgroup2fs，那就是 v2；如果是tmpfs，大概率是 v1。知道了版本，再去查对应的接口文件，就能少走很多弯路。

5.3 容器里执行 ps 还是看到宿主机进程

这个坑几乎每个新手都会踩。你进入新的 PID namespace 后，执行ps aux，结果发现进程列表和宿主机一模一样。

原因我已经在前面提到过：ps命令读取的是/proc文件系统，而/proc是动态生成的，内容取决于它所在的 mount namespace 视图。你如果没有为新的 PID namespace 挂载新的/proc，那么它看到的就是宿主机的/proc。

解决办法：在执行unshare时加上--mount-proc，或者手动执行mount -t proc proc /proc。记住一个原则：新的 PID namespace 必须搭配新的 proc 挂载，否则隔离视图就是假的。

5.4 容器里执行 ping 或 ifconfig 找不到命令

BusyBox 的极简根文件系统里，默认可能没有网络相关的工具，或者你没有创建 Network namespace，所以网络视图还是和宿主机共享的。

如果你只是想快速验证“网络隔离”，可以在unshare里加上--net。你会看到容器里没有网卡、没有 IP，因为新的 Network namespace 默认只有一块虚拟的回环设备lo。真正的容器网络是由 Docker 这样的运行时帮你创建虚拟网桥、veth 对等设备来打通的。

5.5 所有实验都要在安全可控的环境下进行

这一点我必须强调。namespace 虽然能隔离视图，但它不是万能的“保险箱”。没有配置额外安全机制的情况下，容器内如果存在内核漏洞，是有可能影响宿主机的。所以强烈建议你所有的实验都在虚拟机、或临时云主机上进行，不要在没有任何隔离的物理机上乱试。

顺便说一句，如果你想用这个思路在真实项目里做点轻量级的“环境隔离”工具，利用unshare+ cgroup 是一个性价比很高的方案。但请务必读透内核文档，把安全边界搞清楚再上生产。

6. 我在实际折腾中的一点体会

踩过这么多坑之后，我最大的体会是：技术圈里所谓“高深”的东西，大部分是工程化包装带来的表象。如果你能扒开包装，找到它要解决的那个最原始的问题，技术本身往往简单得惊人。

容器技术就是最典型的例子。它的核心不是 Docker、不是 Kubernetes、不是那些花哨的编排概念，而是 Linux 内核里两个朴素的机制：一个管“你能看到什么”，一个管“你能用多少”。Docker 做的事情，充其量是给这两个机制穿了一件更合身的衣服，然后设计了完整的分发体系。

所以我建议你，以后遇到任何新技术，先别急着抄文档。试着问自己三个问题：它解决的核心问题是什么？它用了哪些操作系统或硬件层面的基础能力？这些东西和我已知的哪些概念是相通的？想通这三个问题，你再看那些被包装得高深莫测的架构文章，就会有一种“不过如此”的通透感。

最后分享一个小技巧：遇到一个复杂系统，去找它的 Minimal Reproduction，也就是最小复现路径。像我们这次用一条unshare命令复现了容器的核心机制，这种“最小复现”的思维方式，对理解任何复杂技术都比看十篇架构分析管用。