自研容器第一层：UTS Namespace隔离与Go实现

1. 为什么 UTS Namespace 是自研容器绕不开的第一层自己动手做一个容器运行时第 0 步往往不是写代码而是先弄明白内核把隔离这件事拆成了多少个抽屉。抽屉一共有好几个但真正适合第一个下手的只有UTS Namespace。原因很朴素它隔离的东西少得可怜只包含主机名和域名两个字段改起来立竿见影出错也炸不掉你的网络和磁盘。我当初拆解容器隔离机制时就是从 UTS 开始敲的一条unshare命令下去hostname一改宿主机纹丝不动那种原来隔离是这么回事的感觉比看十篇原理文章都管用。这一章先把底层的账算清楚UTS 这三个字母代表什么它到底在内核里存了哪些字节为什么它是自研 Docker 路上最该先啃的一块骨头。理解了这些后面写unshare系统调用的代码才不会变成抄作业。1.1 容器里那个看起来随机的主机名究竟存在哪很多人第一次进容器hostname一敲出来一串十六进制字符第一反应是这玩意儿是不是随机生成的配置文件。不是。它压根不在文件系统里而是躺在一个叫uts_namespace的内核结构体中这个结构体里嵌着一个new_utsname包含六个字符数组sysname、nodename、release、version、machine、domainname。我们平时敲hostname命令改的只是nodename这一个字段uname -a打出来的那一长串其实把sysnameLinux、release内核版本、machine架构全读出来了。默认情况下系统上所有进程共享同一个初始 UTS 名字空间内核源码里叫init_uts_ns所以你在任何终端改主机名全局都变——因为它改的是同一块内存。这里有个容易被忽略的细节hostname命令只改内存不写磁盘。你改完之后/etc/hostname这个文件还是老内容重启就恢复。这一点对做容器的人其实是好事意味着隔离天然就是进程级的不需要动任何持久化配置也不会有容器退出后宿主机主机名被污染的隐患。1.2 名字空间的边界怎么判定一个 inode 号就够了判断两个进程是不是在同一个 UTS 名字空间不需要什么高级工具看一个符号链接就行/proc/pid/ns/uts。这个链接指向的内容形如uts:[4026531838]中括号里的数字就是该名字空间对应内核对象的 inode 编号。两个进程读出来数字一样就是同一个空间不一样就是隔离的。# 宿主机上 readlink /proc/self/ns/uts # 输出类似uts:[4026531838] # 在新 UTS 名字空间里再读一次 sudo unshare --uts --fork readlink /proc/self/ns/uts # 输出类似uts:[4026532xxx]编号变了这个 inode 号是我调试命名空间问题时用得最多的东西比任何工具都快。因为它不依赖环境、不依赖命令是否存在只要/proc挂着就能读。后面我们会用nsenter进入某个进程的名字空间本质也是根据这个编号去找内核对象。1.3 为什么偏偏先拿它练手三个实打实的理由第一个理由是效果肉眼可见。网络名字空间隔离之后你得先建 veth pair、配路由、开 NAT才能验证通不通挂载名字空间隔离之后你得处理 pivot_root、proc 重挂载一不小心就把宿主机搞成只读。UTS 不用unshare一敲hostname一改hostname再敲变化立刻呈现验证成本几乎为零。第二个理由是权限模型单一。创建 UTS 名字空间只需要一个能力CAP_SYS_ADMIN。在普通 root 权限下就能干不用碰 cgroup、不用碰 seccomp也不会有某些发行版默认关掉了 user namespace这类意外。整个实验链条只有一条权限线出问题好定位。第三个理由是失败成本低。就算你把unshare用错了最坏结果也就是当前这个 shell 的 hostname 变了exit之后一切复原。对比之下网络名字空间搞错了可能直接断掉你的 SSH 连接那时候只能去机房按电源键。做底层实验先挑一个炸不死人的模块上手是性价比最高的策略。还有一层隐性收益UTS 的代码路径和后面 PID、Mount 名字空间的代码路径高度相似都是unshare/clone加一个标志位。把这个最小模型跑通后面加CLONE_NEWPID、CLONE_NEWNS基本就是改个常量、调一下进程模型的事。骨架搭对了后面是长肉。2. 用 unshare 命令先跑通再谈写代码写代码之前先在命令行把效果验证一遍是我这些年养成的固定动作。原因很实在命令行工具本身就是系统调用的薄封装它的行为就是内核行为的直接体现先用它把预期结果钉死再去写 Go 代码你就有了一个可靠的对照组。一旦代码跑出来的结果和命令行不一致问题一定在你的代码里而不是在我以为内核应该这样里。unshare这个命令来自 util-linux 包绝大多数发行版默认就有。它干的事情非常简单调用unshare(2)系统调用把指定的名字空间拆出来然后执行你给的命令。2.1 三条命令看清隔离效果先开一个终端记录当前主机名和名字空间编号hostname readlink /proc/self/ns/uts然后进入一个新的 UTS 名字空间sudo unshare --uts --fork /bin/bash进去之后先确认自己确实换了空间readlink /proc/self/ns/uts # 编号应该和外面不一样 hostname mycontainer # 改主机名 hostname # 输出 mycontainer关键的一步验证在另一个终端里做不退出这个 shell另开一个窗口敲hostname你会发现宿主机的主机名原封不动。这就说明隔离生效了——你改的是新名字空间里那块new_utsname跟宿主机的init_uts_ns是两个不同的对象。退出这个 shellexit再敲hostname一切复原。因为那个名字空间里已经没有活着的进程了内核把它回收掉你自然回到初始空间。2.2 参数逐个拆--uts、--fork到底在干什么--uts是最核心的对应内核标志位CLONE_NEWUTS十六进制值是0x04000000。这个常量在后面写 Go 代码时会直接用到现在先记下。--fork容易被新手忽略但它的作用不小。不加--fork时unshare命令直接在当前进程上调用unshare()然后exec你给的命令进程号不变。加了--fork它会先fork()出一个子进程在子进程里做unshare()再exec。两种方式对 UTS 来说结果一样但--fork更接近真实容器的行为模型容器进程是父进程 fork 出来的父进程也就是容器运行时留在原来的名字空间里方便后续做清理、收尸、信号转发。还有几个参数值得提一句。--mount-proc是用来配合 PID 名字空间的它会在新的 mount 名字空间里重新挂载/proc否则你看到的进程列表还是宿主机的。这一步在 UTS 阶段用不上但等我们做到 PID 隔离那一步不加它就会出现我明明隔离了 PID怎么ps还能看到外面一堆进程的经典困惑。提前知道有这么个开关能省掉一次抓瞎。2.3 命令行验证阶段的两个坑第一个坑非 root 用户直接unshare --uts会失败。报错一般是unshare failed: Operation not permitted。因为创建 UTS 名字空间需要CAP_SYS_ADMIN普通用户没有。想在没有 root 的环境里玩可以走 user namespace 路线unshare --user --map-root-user --uts /bin/bash先在 user namespace 里把自己映射成假 root拿到该 user namespace 内的CAP_SYS_ADMIN再创建 UTS 名字空间。这条路在不少发行版上默认可用但它牵扯到 user namespace 的权限模型坑比直接用 root 多得多。做实验阶段我建议直接用 root把变量控制到最少。第二个坑误以为hostname命令改了配置文件。有些人改完主机名退出名字空间后发现宿主机/etc/hostname里躺着自己刚才起的容器名一脸茫然。实际上hostname命令默认只改内核内存不写文件如果你用的是某些带--static参数或者特定发行版的封装脚本才可能落盘。稳妥的做法是全程只用hostname name这种不带额外参数的调用确保改动只在内存里退出即恢复。再补一个验证技巧想知道某个正在运行的进程在哪个 UTS 名字空间可以直接nsenter进去看看nsenter --target pid --uts hostname这个命令按 PID 找到目标进程切进它的 UTS 名字空间执行hostname输出就是那个空间里的主机名。后面我们写 Go 程序时用这招验证隔离效果最直接。3. Go 里直接调 unshare 系统调用代码逐段拆解命令行能跑通说明内核这一侧没问题剩下的就是把同样的动作翻译成代码。用 Go 做这件事有一个天然优势标准库里的syscall包已经把 Linux 的系统调用封装好了syscall.Unshare、syscall.Sethostname、syscall.Exec三个函数就够用不需要 cgo不需要引入第三方库。下面的代码是我这个阶段实际用的最小版本去掉了一切花哨的东西只保留创建 UTS 名字空间 → 改主机名 → 执行 shell这条主干。3.1 工程结构与依赖目录结构简单到不能再简单mybox/ ├── go.mod └── main.go初始化命令mkdir mybox cd mybox go mod init myboxgo.mod里不需要任何require因为全部走标准库。这里要提醒一句syscall.Unshare只在 Linux 上有定义如果在其他系统上编译会报错所以编译时最好显式指定GOOSlinux避免在别的平台上折腾半天。3.2 完整代码package main import ( fmt os syscall ) func main() { // 1. 创建新的 UTS 名字空间 if err : syscall.Unshare(syscall.CLONE_NEWUTS); err ! nil { fmt.Fprintf(os.Stderr, unshare(CLONE_NEWUTS) 失败: %v\n, err) os.Exit(1) } // 2. 在新空间里设置主机名默认 mybox可由参数覆盖 hostname : mybox if len(os.Args) 1 { hostname os.Args[1] } if err : syscall.Sethostname([]byte(hostname)); err ! nil { fmt.Fprintf(os.Stderr, sethostname(%q) 失败: %v\n, hostname, err) os.Exit(1) } // 3. 用 shell 替换当前进程 shell : /bin/sh if _, err : os.Stat(/bin/bash); err nil { shell /bin/bash } if err : syscall.Exec(shell, []string{shell}, os.Environ()); err ! nil { fmt.Fprintf(os.Stderr, exec(%q) 失败: %v\n, shell, err) os.Exit(1) } }代码不到四十行但每一行都有它的位置。3.3 逐段解析三个调用各自解决了什么问题第一段syscall.Unshare(syscall.CLONE_NEWUTS)。这个函数直接对应unshare(2)系统调用参数是标志位。syscall.CLONE_NEWUTS在标准库里的值就是0x04000000跟命令行--uts完全等价。调用成功之后当前进程就从原来的 UTS 名字空间脱离出来拥有一个全新的、内容复制自旧空间的副本。注意这里的关键词是副本新空间里的主机名初始值和宿主机一样不是空的所以如果不调用Sethostname你在里面敲hostname看到的还是宿主机那个名字容易误判成没隔离成功。错误处理这里值得多说一句。Unshare失败最常见的两个 errno 是EPERM和EINVAL。EPERM基本就是权限不够没拿 root 跑EINVAL一般是标志位组合有问题比如某些名字空间类型不允许在同一个调用里一起创建或者进程状态不满足要求。把原始 error 打出来而不是吞掉能省掉大量猜测时间。第二段syscall.Sethostname([]byte(hostname))。对应sethostname(2)作用范围是当前进程所在的 UTS 名字空间。因为上一步已经切到新空间了这一改只影响自己宿主机完全无感。参数是[]byte长度有上限内核里nodename是 65 字节的数组正常的主机名远够用。这里有个细节Sethostname要求调用者在该 UTS 名字空间所属的 user namespace 里拥有CAP_SYS_ADMIN。用 root 跑自然满足如果走 user namespace 那条路就需要先完成 uid 映射。第三段syscall.Exec(shell, []string{shell}, os.Environ())。为什么用Exec而不是fork一个子进程因为容器里 PID 1 的行为有特殊性它要负责收尸回收孤儿进程、要能正确响应信号。如果在 Go 程序里 fork 一个子进程再 wait那 Go 程序本身才是 PID 1信号转发、退出码传递都得自己处理麻烦。直接用execve把当前进程映像替换成 shell进程号不变信号直达退出码天然透传是最省心的做法。os.Environ()把当前环境变量原样传过去包括PATH、HOME、TERM。这一步别省否则进去之后ls都可能找不到还以为是隔离把文件系统搞坏了。3.4 编译、运行、验证# 编译 GOOSlinux go build -o mybox . # 运行需要 root sudo ./mybox mycontainer # 进去之后 hostname # 输出 mycontainer readlink /proc/self/ns/uts验证分三处做。第一处在这个 shell 里hostname应该输出你传进去的名字。第二处在宿主机另开一个终端hostname必须还是原来的名字readlink /proc/self/ns/uts的编号必须和里面那个不同。第三处更硬核找到这个 shell 的 PID用nsenter从外面切进去验证。# 在宿主机上找到 mybox 相关进程 ps -ef | grep mybox # 用 nsenter 进入它的 UTS 名字空间 sudo nsenter --target pid --uts hostname如果nsenter打出来的是mycontainer说明隔离这件事你已经真正做到了不是看起来像。3.5 权限、进程模型与几个必须提前知道的细节为什么要 root。前面说过CLONE_NEWUTS需要CAP_SYS_ADMIN。这意味着你在开发阶段所有测试都得带sudo而这恰恰引出了下一章要讲的麻烦事——sudo之后你的 Go 工具链可能就找不到了。关于多线程。有些名字空间类型比如 PID对调用进程是否多线程有要求因为 Go 运行时默认会起多个系统线程直接在某些场景下调Unshare可能拿到EINVAL。UTS 这一层目前没这个问题可以直接在当前进程上调。但等你往下做到 PID 隔离就得换成重新 exec 自己的模型父进程fork出子进程子进程exec自身并带上一个环境变量标记新一轮启动时再调unshare(CLONE_NEWPID)。这个套路是绝大多数用 Go 写的容器运行时的通用做法提前知道后面就不会卡住。关于exec的路径。代码里做了一次/bin/bash存在性检查回退到/bin/sh。因为有些精简镜像里没有 bash硬编码路径会直接报no such file or directory。这不是洁癖是实际会遇到的你换一台机器跑路径就没了。关于argv[0]。syscall.Exec(shell, []string{shell}, ...)里第二个参数的第一个元素是argv[0]习惯上写成命令名本身。有些程序比如某些 shell会根据argv[0]判断自己的行为模式比如-bash表示登录 shell。传错虽然大多数时候不影响但遇到诡异行为时这里是第一个该检查的地方。4. root 用户找不到 go 命令一次典型的 PATH 事故上面那段代码写完兴冲冲地敲sudo go run main.go终端回你一句sudo: go: command not found。而同一个目录下不加sudo的go version一切正常。这个场景我见过太多次几乎是每个用 Go 写底层工具的人都会撞一次的墙。它跟 Go 本身没关系跟代码也没关系纯粹是sudo的环境处理机制造成的。搞明白这一层你以后再遇到sudo python、sudo node找不到命令都能一秒定位。4.1 现象复现与环境差异先看两边环境变量的差别这是最直观的定位手段# 普通用户 which go echo $PATH # root 下 sudo which go sudo sh -c echo $PATH绝大多数情况下普通用户的PATH里包含类似/usr/local/go/bin或者$HOME/sdk/go1.xx/bin、$HOME/go/bin这样的路径而sudo出来的PATH变成了/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin这种标准系统路径缺少了 go 所在的目录。再进一步which go的输出也能说明问题。如果它指向的是~/go/bin/go或者~/sdk/...那 root 根本访问不到这个路径——就算PATH对上了/root和/home/xxx也是两套目录。4.2 根因拆解sudo 到底动了哪几样东西原因有三层逐层剥开看。第一层sudo不读你的 shell 配置文件。你的PATH是在~/.bashrc、~/.profile、~/.zshrc里通过export PATH...加进去的。这些文件只在交互式 shell 启动时被 source。sudo的做法是直接execve目标命令中间不经过任何 shell自然也不会有任何 rc 文件被执行。所以那些export全部失效。第二层env_reset。sudo默认开启env_reset会把环境变量重置成一个白名单集合只保留少数几个比如TERM、LANG和 sudoers 里env_keep指定的变量。PATH通常不在保留名单里。第三层secure_path。这是最容易被忽略的一层。很多发行版的默认 sudoers 配置里有一行Defaults secure_path...它会用一个固定的安全路径覆盖掉调用者的PATH而且这个覆盖的优先级很高即使你用了sudo -E保留环境PATH也可能照样被它替换。这就是为什么很多人试了-E之后发现还是不行一脸懵。三层叠加的结果就是sudo执行时PATH是一个跟你当前 shell 完全无关的值go 自然找不到。4.3 四种解法的实测对比方案命令写法优点缺点适用场景绝对路径sudo /usr/local/go/bin/go run main.go最简单零配置每次都要打全路径容易忘临时跑一次env 透传sudo env PATH$PATH go run main.go不改任何配置一次生效命令长HOME未透传时缓存仍分离日常开发最常用软链接sudo ln -s /usr/local/go/bin/go /usr/local/bin/go之后sudo go直接可用系统级改动升级 Go 后链接可能失效长期在这台机器上折腾改 sudoerssudo visudo里在secure_path追加 Go 目录一次配置全局生效改动系统安全配置多人机器上要慎重个人专用实验机我自己日常用的是第二种因为不动系统配置命令写长一点无所谓还能顺手把HOME一起传进去sudo env PATH$PATH HOME$HOME go run main.go第三种我一般只在实验机上用好处是后面写脚本、写 Makefile 时不用到处加env命令看着干净。但要注意软链接的源路径必须硬编码换一台机器、换一个 Go 版本安装位置就断了所以脚本里如果依赖它最好加一句检查。第四种改动最大visudo打开/etc/sudoers找到Defaults secure_path...那一行在引号内的路径列表末尾追加:/usr/local/go/bin。改完之后新开的终端立刻生效。这里必须强调只能用visudo编辑它会做语法检查直接改文件万一写错一个字符可能所有人都 sudo 不了那台机器就得进救援模式了。4.4 顺带解决 GOCACHE 与模块缓存的重复下载PATH解决了下一个坑紧随其后。sudo go build跑起来之后你会发现它开始重新下载依赖编译速度也慢了一大截。原因还是环境变量HOME被重置成/root于是GOPATH变成/root/goGOMODCACHE变成/root/go/pkg/modGOCACHE变成/root/.cache/go-build。你之前在用户目录下攒的依赖和编译缓存root 一个都用不上。解决办法还是透传HOME或者显式指定这三个变量sudo env PATH$PATH HOME$HOME go run main.go # 或者只指定缓存相关变量 sudo env PATH$PATH GOCACHE$HOME/.cache/go-build GOMODCACHE$HOME/go/pkg/mod go run main.go还有一个更稳妥的思路能不用 root 编译就别用 root 编译。先用普通用户go build -o mybox .生成二进制再sudo ./mybox只把运行阶段提权。编译不需要任何特权运行才需要CAP_SYS_ADMIN。把权限需求精确到只有运行这一步需要是最省事的做法也避免了 root 的缓存目录里堆一堆莫名其妙的文件。再补一个实际会遇到的衍生问题如果项目里用了 cgo这个 demo 用不到但后面做网络配置时可能会碰sudo环境下CC、CGO_ENABLED也可能丢失表现为莫名其妙的编译错误。排查思路一样先用sudo env把当前go env的输出整体透传过去试试。5. 常见问题速查与踩坑记录到这一步UTS 名字空间的最小闭环已经打通了能建、能改、能验证、能从外部nsenter进去检查。但真正动手的时候问题往往出在意料之外的地方而不是核心逻辑里。这一章把我实际踩过的坑整理成速查表再补几条不太好归类但很值钱的经验。5.1 问题速查表现象可能原因排查动作解决方式sudo go: command not foundsudo 重置 PATHsecure_path覆盖sudo sh -c echo $PATH对比sudo env PATH$PATH go ...unshare: Operation not permitted缺CAP_SYS_ADMINid确认是否 root用 root 或走 user namespacesethostname: operation not permitted名字空间已建但权限不足检查是否在 user ns 内映射补 uid 映射或直接 root 运行进去之后hostname没变忘了调Sethostname只是复制了副本加日志打印调用结果显式设置主机名退出后宿主机主机名变了没做隔离直接改的全局检查是否调用了Unshare确认CLONE_NEWUTS生效每次sudo go build都重新下载依赖HOME被重置缓存目录分离sudo go env GOCACHE透传HOME或显式指定缓存exec: no such file or directoryshell 路径不存在ls /bin/bash回退到/bin/shnsenter报找不到进程PID 写错或进程已退出ps -ef确认用存活进程的 PID5.2 我在这个环节踩过的几个坑坑一以为unshare之后主机名会自动变。第一次跑的时候我在新 shell 里敲hostname输出和外面一模一样当场怀疑隔离没生效。实际上新名字空间是旧空间的完整副本主机名当然一样。判断是否隔离要看/proc/self/ns/uts的 inode 编号不能看主机名。这个认知纠正过来之后后面所有名字空间的调试思路都顺了先看编号再看内容。坑二在go run和go build之间反复横跳。go run会先编译再执行中间多一层进程sudo环境下路径问题会让报错信息变得很难读。后来我固定成普通用户编译、root 运行二进制的流程报错清晰速度也快。这个习惯一直保留到现在凡是涉及提权的实验编译和执行严格分离。坑三nsenter进去看不到变化。有一次我用nsenter --target pid --uts hostname验证结果输出还是宿主机名。查了半天发现pid填的是sudo包装进程的 PID而不是真正跑在名字空间里的那个 shell 的 PID。sudo会 fork 出子进程ps -ef里能看到父子关系选错了就白忙活。正确做法是找那个mybox或者 shell 本身的 PID。坑四容器退出后hostname的残留错觉。有次退出 shell 之后我在同一个终端里发现hostname还是容器名。原因是那个终端的 shell 提示符缓存了旧值或者我压根没退出干净。后来养成习惯验证隔离一定新开一个终端做不跟当前会话混在一起避免自己骗自己。坑五sudo下的go版本和普通用户不一致。系统里可能装了两个 Go一个在/usr/local/go一个是通过包管理器装的/usr/bin/go。普通用户PATH优先命中前者sudo的secure_path只包含/usr/bin于是命中了后者版本天差地别编译报错莫名其妙。排查方式很简单两边都跑which go go version对比一下一眼就能看出来。5.3 下一步把 UTS 和 PID 组合起来单跑 UTS 只能证明名字空间机制是通的离容器还差得远。下一步自然是把 PID 名字空间加进来unshare的调用要从当前进程改成重新 exec 自己的模型因为 PID 名字空间要求创建者本身不在新空间里得让子进程成为新空间的第一个进程也就是 PID 1。到那一步几个新问题会冒出来/proc必须重新挂载否则进程列表还是外面的PID 1 要处理僵尸进程回收否则容器里会堆积一堆 defunct--mount-proc这个参数必须在 mount 名字空间里做也就是说你得同时引入CLONE_NEWNS。这些问题串起来正好构成了一个迷你容器运行时的雏形。我的建议是别急着一次全上。先把 UTS 这一层的代码单独提交一次跑通、验证、写下笔记再动 PID。因为一旦引入 PID 和 mount调试难度会陡增一个数量级——ps看不到进程、/proc挂载失败、exec路径找不到这些错误信息会互相掩盖让你分不清到底是哪一层出了问题。一次只加一个变量是这个阶段最值钱的纪律。