容器化实战：Namespace + cgroup 手搓一个迷你容器——内部创业公司的独立运营

容器化实战Namespace cgroup 手搓一个迷你容器——内部创业公司的独立运营延续《趣谈 Linux 操作系统》的比喻内核是外包总公司进程是内部创业小组。今天我们要干一件更激进的事——给某个小组发一张独立营业执照让它以为自己独占了一整家公司它有自己独立的 hostname以为自己是 CEO、独立的 PID 编号它就是 1 号、独立的文件系统视角、独立的网络甚至独立的预算CPU/内存配额。这就是容器。而 Linux 实现它的两把手术刀正是Namespace隔离视图和cgroup限制资源。0. 引子从共用大办公室到独立子公司总公司宿主机原本是这样的┌─────────────────────────────── 宿主机总公司 ─────────────────────────────┐ │ hostname ecs-44ec-0004 │ │ PID 1: systemd PID 100: nginx PID 200: mysql ... │ │ 网络: eth0 (公网IP) lo │ │ 文件系统: / 根目录 (一整棵目录树) │ │ CPU/内存: 所有进程共享 8核16G │ └───────────────────────────────────────────────────────────────────┘容器化就是在同一栋楼里用隔板隔出一间独立子公司让它产生幻觉┌──────── 子公司A容器 ────────┐ ┌──────── 子公司B容器 ────────┐ │ hostname mini-container │ │ hostname db-container │ │ PID 1: 自己的 init │ │ PID 1: 自己的 init │ │ 网络: 自己的 lo / eth0(veth) │ │ 网络: 自己的 lo / eth0(veth) │ │ 文件系统: 自己的 / (chroot) │ │ 文件系统: 自己的 / (chroot) │ │ 预算: CPU 50% / 内存 50M │ │ 预算: CPU 30% / 内存 256M │ └────────────────────────────────┘ └────────────────────────────────┘ 都跑在同一内核之上但彼此看不见、互不干扰Namespace 负责你以为你独占隔离cgroup 负责你最多只能用这么多限制。两者加起来就是 Docker 的底层真相。下面我们不用 Docker纯手工把它们跑出来。1. 实验环境项目配置机器华为云 FlexusXecs-44ec-0004系统Ubuntu 24.04 LTS内核6.8.0工具util-linux(unshare/ip/netns)、gcc 13.3、busybox-static所有实验在/root/ctlab进行。下列输出全部来自真实机器。2. 实验一Namespace 全家福——/proc/self/ns/Linux 把隔离能力抽象成几种 namespace每个进程在/proc/pid/ns/下都有一组符号链接指向自己所属的命名空间ls-l/proc/self/ns/真实输出total 0 lrwxrwxrwx 1 root root 0 Jul 29 13:06 cgroup - cgroup:[4026531835] lrwxrwxrwx 1 root root 0 Jul 29 13:06 ipc - ipc:[4026531839] lrwxrwxrwx 1 root root 0 Jul 29 13:06 mnt - mnt:[4026531841] lrwxrwxrwx 1 root root 0 Jul 29 13:06 net - net:[4026531840] lrwxrwxrwx 1 root root 0 Jul 29 13:06 pid - pid:[4026531836] lrwxrwxrwx 1 root root 0 Jul 29 13:06 pid_for_children - pid:[4026531836] lrwxrwxrwx 1 root root 0 Jul 29 13:06 time - time:[4026531834] lrwxrwxrwx 1 root root 0 Jul 29 13:06 time_for_children - time:[4026531834] lrwxrwxrwx 1 root root 0 Jul 29 13:06 user - user:[4026531837] lrwxrwxrwx 1 root root 0 Jul 29 13:06 uts - uts:[4026531838]虽然列出来有 10 个文件但对应的是8 种 namespace 类型cgroup / ipc / mnt / net / pid / time / user / utspid_for_children和time_for_children是创建子进程时用的预备视图归到 pid / time 两类里。它们各自管一摊事Namespace隔离了什么类比uts主机名、域名子公司的公司名ipc进程间通信共享内存/消息队列内部通讯录mnt挂载点 / 文件系统视图看到的办公室平面图pid进程号“员工工号体系”net网络栈网卡/IP/端口/路由独立的对外联络部user用户/权限映射“谁能当老板”cgroup看到的 cgroup 视图预算表的可见范围time系统时钟/时钟_namespace自己的打卡时钟两个进程若某个 ns 的 inode 号相同看中括号里的数字说明它们在同一个该命名空间里。3. 实验二UTS Namespace——给子公司起个独立名字uts隔离 hostname。我们用unshare -u开一个独立的 UTS 命名空间在里面改 hostname看宿主机变不变echohost hostname before:$(hostname)unshare-ubash-chostname container-demo echo inside-uts-hostname:$(hostname)echohost hostname after unshare:$(hostname)真实输出host hostname before: ecs-44ec-0004 inside-uts-hostname: container-demo host hostname after unshare: ecs-44ec-0004子公司把自己公司的名字改成了container-demo但总公司宿主机的名字ecs-44ec-0004纹丝不动。这就是 namespace 的精髓隔离是视图级的彼此不串味。4. 实验三PID Namespace——子公司的 1 号员工打开 PID namespace 后容器里第一个进程会成为 PID 1“祖师爷”而且它看不到宿主机的其他进程。注意要用--mount-proc重新挂载/proc否则ps还会读到宿主机的进程目录。unshare-p-f--mount-procbash-cecho\inside shell PID $$\; sleep 10 ps -ef真实输出inside shell PID 1 UID PID PPID C STIME TTY TIME CMD root 1 0 0 13:06 ? 00:00:00 bash -c echo inside shell PID 1; sleep 10 ... root 2 1 0 13:06 ? 00:00:00 sleep 10 root 3 1 0 13:06 ? 00:00:00 ps -ef注意在子公司内部我们的 shell 是PID 1后台sleep是 PID 2ps自己是 PID 3。最重要的——宿主机的 systemd、nginx 等几千个进程一个都看不见。PID 1 在 Linux 里地位特殊它是所有进程的祖先收尸孤儿进程容器里它通常就是你的init如tini/systemd。5. 实验四Mount Namespace——独立办公室平面图mnt隔离能看到哪些挂载点。在独立 mount ns 里挂载一个 tmpfs宿主机完全无感mkdir-p/tmp/mntpoint unshare-mbash-cmount -t tmpfs tmpfs /tmp/mntpoint touch /tmp/mntpoint/inside_file.txt echo inside-mount: ls /tmp/mntpointechohost side /tmp/mntpoint (should be empty):ls-A/tmp/mntpoint真实输出inside-mount: inside_file.txt host side /tmp/mntpoint (should be empty): (end host listing)子公司在自己那张办公室平面图上挂了个临时储物柜tmpfs还放了文件回到总公司一看——平面图干干净净啥都没有。Mount namespace 正是 Docker 镜像每个容器有独立根目录的基石配合pivot_root/chroot。5. 实验五重头戏Network Namespace veth——两家子公司互连这是容器网络的核心。思路创建两个网络命名空间ns1、ns2用一对veth 虚拟网线一头在 ns1、一头在 ns2把它们连起来配好 IP 互 ping。ipnetnsaddns1ipnetnsaddns2iplinkaddveth1typeveth peer name veth2# 造一根两头分别为 veth1/veth2 的虚拟网线iplinksetveth1 netns ns1# 一头插进 ns1iplinksetveth2 netns ns2# 另一头插进 ns2ipnetnsexecns1ipaddradd10.0.0.1/24 dev veth1ipnetnsexecns2ipaddradd10.0.0.2/24 dev veth2ipnetnsexecns1iplinksetveth1 upipnetnsexecns2iplinksetveth2 upipnetnsexecns1ping-c310.0.0.2真实输出节选 3) assign IP and bring interfaces up --- ns1 addresses --- lo UNKNOWN 127.0.0.1/8 ::1/128 veth1if3 UP 10.0.0.1/24 fe80::6c61:ff:fe73:d062/64 --- ns2 addresses --- lo UNKNOWN 127.0.0.1/8 ::1/128 veth2if3 UP 10.0.0.2/24 fe80::98d6:a5ff:fe7d:50d6/64 4) ping ns2 (10.0.0.2) from ns1 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq1 ttl64 time0.031 ms 64 bytes from 10.0.0.2: icmp_seq2 ttl64 time0.029 ms 64 bytes from 10.0.0.2: icmp_seq3 ttl64 time0.025 ms --- 10.0.0.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2035ms 6) route table inside ns1 (isolated from host) 10.0.0.0/24 dev veth1 proto kernel scope link src 10.0.0.1互连拓扑图┌─────────── ns1 ───────────┐ veth 虚拟网线 ┌─────────── ns2 ───────────┐ │ lo (127.0.0.1) │ │ lo (127.0.0.1) │ │ veth1 10.0.0.1/24 ────┼──(peer)───┬───────(peer)─────┼── veth2 10.0.0.2/24 │ └──────────────────────────┘ │ └──────────────────────────┘ │ (两根 veth 是一对数据从一头进另一头出)这其实就是 Docker 默认的bridge网络雏形每个容器一个 netns用 veth pair 把容器连到宿主机的虚拟交换机Linux bridge上。ns1的路由表里只有自己这条直连路由完全不知道宿主机的外网 IP 长啥样——网络隔离达成。最后ip netns del ns1; ip netns del ns2即可干净拆除。6. 实验六cgroup v2——给子公司发预算表Namespace 解决了看得见cgroup 解决用得上多少。这台机器用的是cgroup v2统一层级先确认有哪些控制器可用cat/sys/fs/cgroup/cgroup.controllers真实输出cpuset cpu io memory hugetlb pids rdma misc能管 CPU、内存、IO、进程数pids等。下面分别演示 CPU 和内存。6.1 CPU 预算限制到 50%建一个 cgroup把cpu.max设为50000 100000——含义是每 100000 微秒里最多用 50000 微秒 CPU即50% 单核算力。mkdir/sys/fs/cgroup/demoecho50000 100000/sys/fs/cgroup/demo/cpu.max ./burn/dev/null/dev/null21# burn 是一个死循环做浮点运算的 CPU 消耗程序echo$!/sys/fs/cgroup/demo/cgroup.procs# 把进程塞进这个预算组限制前没进 cgroupvs 限制后进 cgroup的top采样# 限制前 baseline 10644 root ... R 100.0 ... bash # 一个核跑满 100% # 限制后cpu.max50000 100000 10704 root ... R 30~50% ... burn # 被压在 50% 附近top瞬时值有抖动我们用 cgroup 自己的记账cpu.stat精确算 6 秒内的平均占用u1$(awk/usage_usec/{print $2}/sys/fs/cgroup/demo/cpu.stat)sleep6u2$(awk/usage_usec/{print $2}/sys/fs/cgroup/demo/cpu.stat)echousage delta $((u2-u1))usec over 6s $(((u2-u1)/60000))%真实输出burn pid11187, cpu.max50000 100000 usage_usec delta 3034542 usec over 6s wall average CPU 50% of one core (50% is the configured cap) nr_periods60 nr_throttled60 throttled_usec8938194实打实的 50%6 秒内这个原本能跑满 100% 的进程被 cgroup 精确限制到 50%。nr_throttled60表示 60 个调度周期全部触发了限流——预算用光就被请去走廊罚站下个周期再放进来。docker run --cpus0.5底层就是这一行cpu.max。6.2 内存预算超限即破产清算OOM Kill设memory.max8M8 MB 上限再让一个不停malloc的进程进组看它被内核 OOM Killer 干掉mkdir/sys/fs/cgroup/memdemoecho8M/sys/fs/cgroup/memdemo/memory.maxecho0/sys/fs/cgroup/memdemo/memory.swap.max# 关掉 swap逼出 OOM./memeater/dev/nullmemeater.out21echo$!/sys/fs/cgroup/memdemo/cgroup.procswait$!;echoexit code (137被OOM杀死):$?dmesg-T|grep-iEoom|killed processcat/sys/fs/cgroup/memdemo/memory.events真实输出memory.max 8388608 bytes memeater exit code (137SIGKILL/OOM): 137 --- dmesg OOM evidence --- [Wed Jul 29 13:15:33 2026] oom-kill:constraintCONSTRAINT_MEMCG, ... oom_memcg/memdemo, task_memcg/memdemo, taskmemeater,pid12360,uid0 [Wed Jul 29 13:15:33 2026] Memory cgroup out of memory: Killed process 12360 (memeater) total-vm:3125744kB, anon-rss:12160kB, ... CONSTRAINT_MEMCG, oom_memcg/memdemo --- cgroup memory.events (oom count) --- low 0 high 0 max 35 oom 1 oom_kill 1 oom_group_kill 0注意 dmesg 里的CONSTRAINT_MEMCG——这是容器层级的 OOM只杀掉超预算的那个进程绝不会拖垮总公司宿主机。memory.events里oom_kill 1记录了这次清算。docker run -m 8m超限时被杀底层正是这套逻辑。内存和 CPU 这种硬预算加上 namespace 的软隔离子公司就再也闹不出大乱子了。7. 实验七综合手搓迷你容器——unsharechroot把上面几种 namespace 一次性组合再配合chroot切换根目录视图就能得到一个麻雀虽小五脏俱全的迷你容器。我们用busybox一个包含几十个常用命令的静态二制做最小根文件系统# 造一个最小 rootfs把 busybox 复制进去并为常用命令建符号链接mkdir-pminiroot/{bin,proc,sys,etc,root}cp/bin/busybox miniroot/bin/busyboxcdminiroot/binforainshlshostnameidcatpsip;doln-sfbusybox$a;done# 一次性开mount(-m) uts(-u) ipc(-i) pid(-p) net(-n) 新命名空间并 chrootunshare-m-u-i-p-n-f--mount-procchroot/root/ctlab/miniroot /bin/sh-c hostname mini-container echo [UTS] container hostname $(hostname) echo [PID] init pid $$ (进程视图:); /bin/busybox ps echo [MNT] chroot 根目录:; ls / echo [NET] 新网络命名空间里的网卡:; /bin/busybox ip link echo [USER] whoami:; /bin/busybox id 真实输出[host] hostname before ecs-44ec-0004 [UTS] container hostname mini-container [PID] init pid 1 (processes visible from inside): PID USER COMMAND [MNT] chroot rootfs listing (isolated from host /): bin etc proc root sys [NET] network interfaces inside new net ns: 1: lo: LOOPBACK mtu 65536 qdisc noop qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 [USER] whoami: uid0 gid0 groups0 [host] hostname after ecs-44ec-0004隔离效果一览维度容器内看到宿主机总公司UTSmini-containerecs-44ec-0004未受影响PID自己是1只看到容器内进程照常几百万进程MNT只有bin/etc/proc/root/sys完整根目录树NET只有lo回环口还有eth0公网口USERuid0注未单独建 user ns仍是 root同真实的 Docker 容器 unshare开这组 namespace pivot_root切换根比chroot更彻底 用user namespace把容器内的 root 映射成宿主机的普通用户所以我们这里容器内uid0其实等价于宿主机某个普通 uid避免提权风险。我们还差 userns 和真正的镜像分层但独立子公司的骨架已经立起来了。8. 实验八overlayfs——Docker 镜像分层的真相最后一个谜题Docker 镜像为什么能一层层叠起来且容器改动不污染原镜像答案是overlayfs叠加文件系统。它把多个目录叠成一个统一视图lowerdir只读的底层 基础镜像层upperdir可写的顶层 容器运行时改动workdir内部临时工区merged最终呈现给用户的统一视图mkdir-poverlay/lower overlay/upper overlay/work overlay/mergedechoIMAGE-LAYER: nginx.conf from base imageoverlay/lower/nginx.confechoIMAGE-LAYER: readme from base imageoverlay/lower/readme.txtechoCONTAINER-LAYER: operator overrideoverlay/upper/nginx.conf# 上层同名为覆盖mount-toverlay overlay\-olowerdir.../lower,upperdir.../upper,workdir.../work\.../overlay/mergedcatoverlay/merged/nginx.conf# 上层赢了catoverlay/merged/readme.txt# 只存在于下层透传echoRUNTIME logoverlay/merged/app.log# 在 merged 里写lsoverlay/upper# 新文件落在 upperlsoverlay/lower# 底层原封不动真实输出 before mount overlay/lower: nginx.conf readme.txt overlay/upper: nginx.conf merged view (mount后) --- read nginx.conf from merged (which layer wins?) --- CONTAINER-LAYER: operator override of nginx.conf # 上层覆盖下层 --- read readme.txt from merged (only in lower) --- IMAGE-LAYER: readme from base image # 下层透传 write inside merged - goes to UPPER (copy-on-write) merged now: app.log nginx.conf readme.txt upper now: app.log nginx.conf # 新写的 app.log 进了 upper lower unchanged (still only 2 files): nginx.conf readme.txt这就是写时复制Copy-On-Write读的时候按上→下顺序找找到即返回所以上层的nginx.conf覆盖底层写的时候一律落到upper底层lower永远只读、原封不动。因此几百个容器可以共享同一份基础镜像层只读、零拷贝每个容器的修改只记在自己那一份upper里删容器 删upper底层镜像毫发无伤。docker image的每一层本质就是一个lowerdir容器运行时多挂一个upperdir叠起来就是你在容器里ls看到的那个世界。9. 总结今天我们没装 Docker却把容器的两把手术刀亲手操练了一遍Namespace 隔离视图uts主机名、pid进程号容器里你是 1 号、mnt挂载视图、net网络栈、user权限映射……veth pair 互连两个 netns 用一根虚拟网线对连ping通即证明网络隔离与连通同时成立——这正是容器桥接网络的最小单元。cgroup v2 限制资源cpu.max50000 100000把 CPU 精确压到 50%memory.max8M触发CONSTRAINT_MEMCG的 OOM Kill只清算超预算进程、不波及宿主机。综合迷你容器unshare -m -u -i -p -n -f --mount-proc chroot一行命令拉起独立子公司UTS/PID/MNT/NET 全部隔离。overlayfs 分层lower(只读镜像) upper(容器可写) 叠加出统一视图写时复制——Docker 镜像分层的全部秘密。回看引子那张图Namespace 让你以为自己独占一家公司cgroup 让你最多只能用这么多预算overlayfs 让你改东西不脏了原始模板。三者合力才有了今天人手一个、秒级启动的容器。思考题实验三里如果不加--mount-proc在 PID namespace 里跑ps会看到什么为什么必须重新挂载/proc实验五用 veth pair 直连两个 netns。真实 Docker 里容器还能上外网中间多了一层什么提示宿主机的bridgeiptables MASQUERADE实验六的 OOM 日志里出现了CONSTRAINT_MEMCG。如果宿主机物理内存也满了dmesg 里的 constraint 会变成什么两者后果有何不同实验八里如果在merged里删除readme.txt它只存在于 lowerupper里会发生什么提示whiteout 文件实验环境华为云 FlexusXecs-44ec-0004Ubuntu 24.04内核6.8.0。所有命令与输出均在该机真实执行实验后已清理 netns、cgroup 与残留进程。