Docker把Linux藏了12年：2個(gè)內(nèi)核功能騙過(guò)所有人

2024年Stack Overflow開發(fā)者調(diào)查顯示，Docker以57%的采用率穩(wěn)居開發(fā)工具榜首。但一個(gè)荒誕的事實(shí)是：大多數(shù)用了五年以上的工程師，依然以為它在跑"迷你虛擬機(jī)"。

真相是——Docker容器里根本沒(méi)有操作系統(tǒng)。它只是一個(gè)被Linux Namespaces和Cgroups精心包裝的普通進(jìn)程，像給進(jìn)程穿了件隱形斗篷。

第一層偽裝：Namespaces讓進(jìn)程"看不見(jiàn)"彼此

Linux內(nèi)核從2002年開始陸續(xù)引入6種Namespace，Docker用了其中5種。這些Namespace的本質(zhì)是"視野切割器"：同一個(gè)物理機(jī)上的進(jìn)程，彼此看不見(jiàn)對(duì)方的文件、網(wǎng)絡(luò)、用戶甚至進(jìn)程ID。

作者Kvs Vishnu Kumar在測(cè)試機(jī)上跑了組對(duì)比命令。宿主機(jī)上`sudo readlink /proc/1/ns/pid`返回的PID Namespace ID，和`/proc/2/ns/pid`完全一致——所有系統(tǒng)進(jìn)程共享同一個(gè)命名空間。但啟動(dòng)一個(gè)容器后，容器內(nèi)的PID 1（通常是應(yīng)用進(jìn)程）在宿主機(jī)上可能顯示為PID 18473，擁有獨(dú)立的Namespace ID。

這種"雙重身份"就是隔離的魔術(shù)：容器內(nèi)以為是根目錄的`/`，其實(shí)是宿主機(jī)上的`/var/lib/docker/overlay2//merged`；以為獨(dú)立的網(wǎng)絡(luò)棧，只是宿主機(jī)虛擬網(wǎng)橋上的一個(gè)veth對(duì)端。

Mount Namespace負(fù)責(zé)文件系統(tǒng)的視圖欺騙。當(dāng)你執(zhí)行`docker run -v /host/data:/container/data`，內(nèi)核并沒(méi)有復(fù)制數(shù)據(jù)，只是在兩個(gè)Namespace的掛載點(diǎn)表中各加了一條記錄——類似給同一個(gè)房間開了兩扇不同編號(hào)的門。

Network Namespace的玩法更野。每個(gè)容器獲得獨(dú)立的網(wǎng)絡(luò)協(xié)議棧：自己的路由表、防火墻規(guī)則、甚至`localhost`。但物理網(wǎng)卡始終只有一塊，數(shù)據(jù)包通過(guò)veth pair（虛擬以太網(wǎng)對(duì)）在宿主機(jī)和容器間跳轉(zhuǎn)，延遲通常低于0.1毫秒——這是虛擬機(jī)通過(guò)Hypervisor轉(zhuǎn)發(fā)難以企及的數(shù)字。

第二層枷鎖：Cgroups的精準(zhǔn)資源配給

2007年由Google工程師Paul Menage和Rohit Seth提交的Cgroups（Control Groups），最初是為了解決搜索服務(wù)集群的資源爭(zhēng)搶。Docker把它變成了容器的"計(jì)劃經(jīng)濟(jì)委員會(huì)"：CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò)帶寬，全部可以按組配額。

關(guān)鍵設(shè)計(jì)在于層級(jí)結(jié)構(gòu)。Docker為每個(gè)容器創(chuàng)建獨(dú)立的Cgroup，但保留向父級(jí)查詢的接口。執(zhí)行`docker stats`時(shí)，你看到的內(nèi)存使用率并非容器自己上報(bào)，而是宿主機(jī)Cgroup文件系統(tǒng)`/sys/fs/cgroup/memory/docker//memory.usage_in_bytes`的實(shí)時(shí)讀取。

這種"他律"而非"自律"的機(jī)制，解釋了為什么容器永遠(yuǎn)無(wú)法突破資源限制——即使內(nèi)部進(jìn)程試圖瘋狂分配內(nèi)存，內(nèi)核的OOM Killer（內(nèi)存耗盡殺手）也會(huì)優(yōu)先選擇Cgroup內(nèi)最耗資源的進(jìn)程終結(jié)，而非放任其拖垮宿主機(jī)。

CPU限制更具欺騙性。設(shè)置`--cpus="1.5"`時(shí)，Cgroups并非給容器綁定特定核心，而是通過(guò)`cpu.cfs_quota_us`和`cpu.cfs_period_us`兩個(gè)參數(shù)，在每個(gè)100毫秒周期內(nèi)分配150毫秒的CPU時(shí)間。容器感知不到這種切片，只覺(jué)得"CPU有點(diǎn)慢"。

UnionFS：鏡像分層的存儲(chǔ)煉金術(shù)

Docker鏡像的"分層"設(shè)計(jì)常被誤解為版本控制，實(shí)則是UnionFS（聯(lián)合文件系統(tǒng)）的工程妥協(xié)。每個(gè)鏡像層是只讀的，容器啟動(dòng)時(shí)在最上層疊加可寫層，形成"寫時(shí)復(fù)制"（Copy-on-Write）結(jié)構(gòu)。

Overlay2驅(qū)動(dòng)（當(dāng)前默認(rèn)）的實(shí)現(xiàn)細(xì)節(jié)：當(dāng)容器修改文件時(shí)，內(nèi)核檢查該文件是否存在于最上層。若不存在，從下層只讀層復(fù)制到可寫層再修改——類似圖書館的"不外借原件，只提供復(fù)印修改"規(guī)則。這個(gè)復(fù)制動(dòng)作發(fā)生在首次寫入時(shí)，而非容器啟動(dòng)時(shí)，因此鏡像體積和啟動(dòng)速度得以解耦。

一個(gè)被忽視的副作用是：頻繁修改大文件會(huì)導(dǎo)致可寫層膨脹。某電商團(tuán)隊(duì)曾因日志文件未掛載外部卷，導(dǎo)致容器運(yùn)行30天后可寫層占滿宿主機(jī)磁盤，觸發(fā)連鎖故障。

鏡像構(gòu)建時(shí)的緩存機(jī)制同樣依賴分層哈希。Dockerfile每條指令生成一層，層ID由內(nèi)容哈希決定。修改第3行指令后，第4行及之后的緩存全部失效——這是"把變動(dòng)頻繁的指令放后面"這條最佳實(shí)踐的技術(shù)根源。

容器運(yùn)行時(shí)：runc的極簡(jiǎn)暴力

2015年Docker將核心運(yùn)行時(shí)捐贈(zèng)給OCI（開放容器倡議），命名為runc。這個(gè)用Go編寫的工具只有一項(xiàng)任務(wù)：接收J(rèn)SON格式的容器配置（OCI Runtime Spec），調(diào)用Linux系統(tǒng)創(chuàng)建Namespace和Cgroup，最后執(zhí)行用戶指定的進(jìn)程。

整個(gè)過(guò)程可以手動(dòng)復(fù)現(xiàn)。下載任意鏡像的tar包，解壓到目錄，用`unshare`命令創(chuàng)建Namespace，用`cgexec`綁定Cgroup，最后`chroot`切換根目錄——你就擁有了一個(gè)沒(méi)有Docker守護(hù)進(jìn)程的"純血容器"。Docker守護(hù)進(jìn)程（dockerd）和containerd的存在意義，只是把這種手工操作自動(dòng)化、API化、集群化。

這種架構(gòu)分層解釋了Docker生態(tài)的脆弱性：2024年某云廠商的容器服務(wù)故障，根因是containerd與特定內(nèi)核版本的Cgroup v2驅(qū)動(dòng)不兼容，而非Docker本身代碼缺陷。容器技術(shù)的穩(wěn)定性，越來(lái)越取決于宿主機(jī)的內(nèi)核版本和發(fā)行版配置。

安全邊界的設(shè)計(jì)也由此清晰。容器逃逸漏洞通常發(fā)生在Namespace隔離失效或內(nèi)核提權(quán)場(chǎng)景，而非Docker守護(hù)進(jìn)程的代碼漏洞。2022年的"Dirty Pipe"（CVE-2022-0847）影響所有Linux系統(tǒng)，容器只是提供了更便捷的攻擊入口——因?yàn)樗拗鳈C(jī)內(nèi)核被共享，容器內(nèi)的root用戶理論上擁有與宿主機(jī)root相同的內(nèi)核攻擊面。

與虛擬機(jī)的本質(zhì)分野

對(duì)比VMware或KVM虛擬機(jī)的架構(gòu)圖，差異一目了然：虛擬機(jī)需要完整的Guest OS（客戶操作系統(tǒng)），通過(guò)Hypervisor（虛擬機(jī)監(jiān)控器）陷入（trap）敏感指令；容器則直接運(yùn)行在宿主機(jī)內(nèi)核上，所有系統(tǒng)調(diào)用無(wú)需翻譯。

性能數(shù)據(jù)佐證這種差異。啟動(dòng)一個(gè)Ubuntu虛擬機(jī)需要30-60秒，其中絕大部分時(shí)間消耗在Guest OS內(nèi)核初始化；啟動(dòng)一個(gè)Ubuntu容器需要200-500毫秒，因?yàn)樘^(guò)了內(nèi)核啟動(dòng)，直接執(zhí)行`/sbin/init`或指定的應(yīng)用進(jìn)程。內(nèi)存開銷方面，虛擬機(jī)至少預(yù)留512MB給Guest OS，容器則按實(shí)際使用分配，空載Alpine鏡像僅需5MB內(nèi)存。

但代價(jià)是隔離強(qiáng)度的降級(jí)。虛擬機(jī)通過(guò)硬件虛擬化（Intel VT-x/AMD-V）實(shí)現(xiàn)內(nèi)核級(jí)隔離，即使Guest OS內(nèi)核被攻破，攻擊者仍需突破Hypervisor才能觸及宿主機(jī)；容器共享內(nèi)核，一旦Namespace或Cgroups配置失誤，或出現(xiàn)內(nèi)核漏洞，隔離即告失效。

這也是Kubernetes堅(jiān)持"一個(gè)Pod一個(gè)容器"默認(rèn)策略的深層原因——不是技術(shù)限制，而是故障域控制。當(dāng)容器逃逸發(fā)生時(shí)，影響范圍被限制在單個(gè)Pod而非整個(gè)節(jié)點(diǎn)。

從chroot到云原生：被重新發(fā)明的隔離史

1979年Unix V7引入的chroot，是進(jìn)程隔離的原始形態(tài)。它只能改變根目錄視圖，進(jìn)程仍能看見(jiàn)其他進(jìn)程、訪問(wèn)所有網(wǎng)絡(luò)、消耗全部資源。2002年的Mount Namespace、2006年的Process Namespace、2007年的Cgroups，逐步補(bǔ)全了chroot的短板。

Docker的創(chuàng)造性不在于發(fā)明技術(shù)，而在于組合技術(shù)的用戶體驗(yàn)。2013年的首個(gè)版本用單一命令`docker run`封裝了Namespace創(chuàng)建、Cgroup配置、UnionFS掛載、網(wǎng)絡(luò)橋接等十余個(gè)步驟，把"專家級(jí)Linux調(diào)參"變成"復(fù)制粘貼即可運(yùn)行"。

這種封裝也制造了認(rèn)知盲區(qū)。當(dāng)開發(fā)者執(zhí)行`docker exec -it container bash`進(jìn)入容器時(shí)，很少有人意識(shí)到這個(gè)bash進(jìn)程和宿主機(jī)上的bash共享同一個(gè)內(nèi)核調(diào)度器、同一個(gè)TCP/IP協(xié)議棧實(shí)現(xiàn)、同一個(gè)系統(tǒng)調(diào)用表。

云原生時(shí)代的演進(jìn)正在模糊邊界。Kata Containers和gVisor嘗試在容器便捷性和虛擬機(jī)隔離性之間尋找中間地帶：前者用輕量級(jí)虛擬機(jī)運(yùn)行容器鏡像，后者用用戶空間內(nèi)核攔截系統(tǒng)調(diào)用。但這些方案的性能損耗（Kata啟動(dòng)時(shí)間增至2-3秒，gVisor系統(tǒng)調(diào)用延遲增加50-100%）讓它們難以替代標(biāo)準(zhǔn)容器。

Linux內(nèi)核的持續(xù)迭代也在改寫規(guī)則。Cgroup v2（2016年合并，2020年成為多數(shù)發(fā)行版默認(rèn)）統(tǒng)一了資源控制接口，但打破了Docker早期版本的兼容性；eBPF（擴(kuò)展伯克利數(shù)據(jù)包過(guò)濾器）允許在Namespace邊界插入可編程邏輯，Service Mesh的Sidecar模式正借此實(shí)現(xiàn)更高效的網(wǎng)絡(luò)代理。

當(dāng)2024年的工程師在筆記本上敲下`docker run`時(shí)，他們啟動(dòng)的不僅是應(yīng)用進(jìn)程，更是一段跨越45年的操作系統(tǒng)演進(jìn)史——從chroot的簡(jiǎn)陋牢籠，到Namespaces的多維迷宮，再到Cgroups的資源計(jì)劃經(jīng)濟(jì)。而Docker所做的，只是把這堆內(nèi)核特性打包成一個(gè)人人可用的黑色方盒。

那個(gè)黑色方盒里究竟有沒(méi)有魔法？還是說(shuō)，我們只是習(xí)慣了不去打開它？