摘要：面對(duì)平臺(tái)化的競(jìng)爭(zhēng)，推出了調(diào)度引擎，但從未真正流行起來(lái)，因?yàn)檎麄€(gè)行業(yè)更傾向于采用，這是第一次死亡它失去了平臺(tái)之戰(zhàn)。

左耳朵耗子說(shuō)過(guò)一段話，讓人深以為然：

我清楚地看到了 Go 和 Docker 這兩種技術(shù)的生態(tài)圈發(fā)展過(guò)程。讓我收獲最大的并不是這些技術(shù)本身，而是技術(shù)的變遷和行業(yè)的發(fā)展。從中，我看到了非常具體的各種思潮和思路，這些更有價(jià)值...... 這些關(guān)鍵新技術(shù)，可以讓你拿到技術(shù)的先機(jī)。這些對(duì)一個(gè)需要技術(shù)領(lǐng)導(dǎo)力的個(gè)人或公司來(lái)說(shuō)都是非常重要的。

12 月 2 日，Kubernetes 發(fā)布了一則消息，表示將在即將發(fā)布的 Kubernetes 1.20 版本中棄用 Docker 支持。CNCF 大使 Ian Coldwater 特地發(fā)了一條 Twitter 消息，呼吁大家對(duì)此進(jìn)行關(guān)注：“ Kubernetes 中已棄用了 Docker 支持。你需要注意這一點(diǎn)并做一些計(jì)劃。這將破壞你的集群。”

這些舉動(dòng)，在技術(shù)圈子里引起的震蕩就好比又宣布了一次 Docker 的死亡（第一次是“Swarm 的沒落”）。雖然這只是一盤大棋中最無(wú)關(guān)緊要的最后一小步，目的就是讓 Kubernetes“不再依賴”Docker。

容器技術(shù)圈子在短短幾年發(fā)生了一些重大的變數(shù)。

Docker 以提供鏡像打包的創(chuàng)新技術(shù)實(shí)現(xiàn)了“一次構(gòu)建、處處運(yùn)行”的軟件交付方式，開啟了一個(gè)全新的容器時(shí)代。面對(duì)平臺(tái)化的競(jìng)爭(zhēng)，Docker 推出了調(diào)度引擎 Swarm，但 Swarm 從未真正流行起來(lái)，因?yàn)檎麄€(gè)行業(yè)更傾向于采用 Kubernetes，這是 Docker 第一次死亡：它失去了平臺(tái)之戰(zhàn)。2016 年 9 月，Google 和 RedHat 聯(lián)合宣布了“fork Docker”，也就是后來(lái)的 CRI-O 項(xiàng)目，這就是這次棄用事件的起始，同時(shí)也宣告了競(jìng)爭(zhēng)的結(jié)束。

誰(shuí)會(huì)收到影響？

Docker 源于 Linux Container，可以將一臺(tái)機(jī)器的資源分成 N 份容器，做到資源的隔離，并將可運(yùn)行的程序定義為標(biāo)準(zhǔn)的 docker image。相對(duì)來(lái)說(shuō)，Kubernetes 屬于 Docker 容器引擎的上層：編排調(diào)度層，它可以把不同機(jī)器的每份容器進(jìn)行編排、調(diào)度，組成分布式系統(tǒng)。

近幾年，Kubernetes 已經(jīng)成為自有機(jī)房、云上廣泛使用的容器編排方案，最廣泛的使用方式是 Kubernetes+Docker。運(yùn)維工程師一方面用 Kubernetes 中的 kubctl 命令、k8s API 來(lái)操作集群，一方面在單機(jī)用 docker 命令來(lái)管理鏡像、運(yùn)行鏡像。技術(shù)專家楊明越給 InfoQ 總結(jié)道：“多帶帶用 Kubernetes，下層不是 Docker 的情況，并不算很多”。

“棄用 Docker”，具體來(lái)說(shuō)，是 Kubernetes 將在 1.20 版本中棄用 dockershim。它是一個(gè)橋接服務(wù)，幫助 Kubernetes 與 Docker 通信時(shí)屏蔽下層容器運(yùn)行時(shí)之間的差異。

這種橋接服務(wù)帶來(lái)便利性的同時(shí)也帶來(lái)了復(fù)雜性。留著時(shí)間的流逝，這種復(fù)雜性不斷“膨脹”，維護(hù) Dockershim 已成為運(yùn)維 / 開發(fā)人員的沉重負(fù)擔(dān)。在下一版中，去掉 Dockershim 將是一個(gè)極大的簡(jiǎn)化，并且恢復(fù)了調(diào)用的一致性。

盡管 Kubernetes 在發(fā)布消息的時(shí)候，表示開發(fā)人員對(duì)這種轉(zhuǎn)變“不必恐慌”，“Docker 還沒有死，它仍然有其用途”。但顯然 Kubernetes 的解釋并不能令人滿意：“是否有人質(zhì)疑為什么不選擇一種更順暢的遷移方式，而不是像谷歌那樣抨擊 Docker，勸人們趕緊遷移，越快越好”。也有更多開發(fā)人員表達(dá)了他們并不明白接下來(lái)他們需要做些什么。

在生產(chǎn)環(huán)境中，企業(yè)大量的使用的是經(jīng)典 Kubernetes+ Docker 方案，同時(shí)在一些公司的場(chǎng)景中也有多帶帶使用 Docker 的情況。

如果用戶的業(yè)務(wù)部署比較簡(jiǎn)單，規(guī)模也較小，僅僅是為了使用容器做應(yīng)用交付的便利，也沒有其他的功能需求的話，僅僅通過(guò) docker run/docker-compose 這種方式也能管得好的話，實(shí)際上是沒必要非得引入 Kubernetes 這樣非常重的編排組件的。反而直接僅僅使用 Docker 會(huì)更輕量，也更好運(yùn)維。比如 toB 的軟件交付的情況，如果要部署的軟件的部署架構(gòu)比較簡(jiǎn)單的話，僅僅涉及少量幾臺(tái)機(jī)器，服務(wù)進(jìn)程也不多的情況下，也有不少是直接使用 Docker，而不引入 Kubernetes 的，比較輕量、簡(jiǎn)單。

還有一個(gè)就是，使用 kubernetes 做編排引擎的情況下，實(shí)際開發(fā)者在日常的開發(fā)中，也會(huì)比較多地使用 Docker。

“對(duì)于一般的應(yīng)用開發(fā)者來(lái)說(shuō)，他們一般不會(huì)直接去面對(duì) Kubernetes 的，因此，對(duì)于他們來(lái)說(shuō)，可能壓根就是無(wú)感知的，應(yīng)用開發(fā)者甚至都不用知道他們的業(yè)務(wù)是用容器運(yùn)行的。對(duì)于整個(gè)基于 Kubernetes 生態(tài)的各個(gè)解決方案提供商來(lái)說(shuō)，由于當(dāng)前基于 Kubernetes 的編排是事實(shí)標(biāo)準(zhǔn)，容器的鏡像格式又是都遵守 OCI 的，因此可以說(shuō)所有的之前的交付的構(gòu)件，無(wú)論容器運(yùn)行時(shí)怎樣變化，實(shí)際上都不會(huì)有啥影響。”網(wǎng)易輕舟容器平臺(tái) NCS 負(fù)責(zé)人王新勇在接受 InfoQ 的采訪中表示，“但對(duì)于容器平臺(tái)提供商來(lái)說(shuō)，可能需要一些適配和準(zhǔn)備動(dòng)作。”

根據(jù) Sysdig 發(fā)布的 2019 年容器使用報(bào)告顯示，Docker 占據(jù)了容器平臺(tái)市場(chǎng)的大部分份額，占比為 79%，而排在第二位的是 containerd，占比為 18%，排在第三位的 CRI-O 項(xiàng)目，占比為 4%。

CRI-O 是 Kubernetes 的輕量級(jí)運(yùn)行時(shí)，希望繞過(guò)現(xiàn)有 Docker 容器的大部分機(jī)制直接操作 Linux 容器，由 RedHat 主導(dǎo)，并且也是目前 Kubernetes 推崇的方式。

“網(wǎng)易已經(jīng)有比較好的準(zhǔn)備，實(shí)際上 Kubernetes 棄用 Docker 從很早就開始討論了。很早我們就開始關(guān)注和使用 Containerd 作為我們的容器運(yùn)行時(shí)的一個(gè)選項(xiàng)了。后續(xù)我們會(huì)提供相關(guān)的運(yùn)行時(shí)多個(gè)選項(xiàng) ，并逐步過(guò)渡到使用 Containerd 作為運(yùn)行時(shí)。”王新勇表示。

“我們還可以通過(guò)將 Dockershim 從 Kubernetes 中摳出來(lái)，獨(dú)立運(yùn)行，作為 Kubernetes 的 cri 到 Docker API 的適配器，實(shí)現(xiàn) Kubernetes 繼續(xù)支持 Docker，從而保持之前的使用習(xí)慣。”

楊明越也認(rèn)為由于老技術(shù)實(shí)現(xiàn)的慣性，在生產(chǎn)環(huán)境大量使用的經(jīng)典 Kubernetes+ Docker 方案依然運(yùn)行，且運(yùn)維已經(jīng)成熟，不會(huì)很快升級(jí)。對(duì)于開發(fā)人員、企業(yè)，對(duì)于 K8S API 的使用頻率、變數(shù)，遠(yuǎn)遠(yuǎn)大于 Docker API，至于 Kubernetes 和 Docker 的橋接，更不用關(guān)心。因此，即便“徹底棄用 Docker”，對(duì)開發(fā)者與企業(yè)的影響也非常有限。

Docker 會(huì)消亡嗎？

Docker 和 Kubernetes 的往事已經(jīng)非常久遠(yuǎn)，從親密伙伴到反目成仇，令人不勝唏噓。
2013 年，當(dāng)時(shí)名叫 dotCloud 的 Docker 公司，開源出來(lái)了自己的容器項(xiàng)目 Docker。Docker 通過(guò)鏡像打包的方式保持了本地環(huán)境和云端環(huán)境的高度一致，解決了運(yùn)維人員的一大心病，將運(yùn)維人員從一遍遍的重復(fù)勞動(dòng)中解放了出來(lái)。同時(shí)友好簡(jiǎn)潔的封裝，對(duì)開發(fā)人員十分具有親和力，這讓 Docker 一舉走紅。很多后端和云計(jì)算領(lǐng)域的優(yōu)秀的開發(fā)力量都匯集在了 Docker 的周圍，生態(tài)一時(shí)間變得異常繁榮。

但此時(shí)的這個(gè)開源創(chuàng)業(yè)公司還必須考慮盈利壓力，于是 dotCloud 公司決定將公司名稱改為“Docker”。將這個(gè)開源項(xiàng)目的名稱變成了 Docker 公司的注冊(cè)商標(biāo)，這意味著，任何人在商業(yè)活動(dòng)中使用這個(gè)單詞，以及鯨魚的 Logo，都會(huì)立刻受到法律警告。

2014 年到 2015 年期間，是容器技術(shù)的鼎盛時(shí)期，Docker 公司一家獨(dú)大，具有十足的話語(yǔ)權(quán)，主導(dǎo)著整個(gè)社區(qū)的發(fā)展。Google 公司曾向 Docker 公司表達(dá)了合作的愿望，希望共同推進(jìn)一個(gè)中立的容器運(yùn)行時(shí)（container runtime）庫(kù)作為 Docker 項(xiàng)目的核心依賴。不過(guò)，Docker 公司并沒有認(rèn)同這個(gè)明顯會(huì)削弱自己地位的提議，不久后 Docker 自己還發(fā)布了一個(gè)容器運(yùn)行時(shí)庫(kù) Libcontainer。

作為開源生態(tài)的一部分，Docker 還缺少有效的商業(yè)模式，他們將眼光放到了容器編排領(lǐng)域，推出了 Swarm。作為 Docker 項(xiàng)目早期的重要貢獻(xiàn)者，RedHat 對(duì) Docker 公司的這個(gè)平臺(tái)化戰(zhàn)略表示很不滿并憤憤退出該項(xiàng)目。

面對(duì) Docker 的強(qiáng)硬態(tài)度，Google 聯(lián)合 RedHat，共同牽頭發(fā)起了一個(gè)名為 CNCF（Cloud Native Computing Foundation）的中立基金會(huì)，來(lái)推動(dòng) Kubernetes 的發(fā)展。

從此之后，面對(duì) Kubernetes 社區(qū)的崛起和壯大，Docker 公司不得不面對(duì)失敗的現(xiàn)實(shí)。2017 年 Docker 公司宣布將 Docker 項(xiàng)目改名為 Moby，交給社區(qū)自行維護(hù)，而 Docker 公司的商業(yè)產(chǎn)品將占有 Docker 這個(gè)注冊(cè)商標(biāo)，希望以此將原本屬于 Docker 社區(qū)的用戶轉(zhuǎn)化成了自己的客戶。

楊明越認(rèn)為現(xiàn)在的 Kubernetes，從技術(shù)上可以說(shuō)是非常開放的產(chǎn)物，但 Docker 已經(jīng)不是。開源社區(qū)的 Moby 項(xiàng)目，圖標(biāo)由一條鯨魚變成了一條鯨魚的尾巴，也可以看出Docker 對(duì)開源版本的態(tài)度。原本是開源的項(xiàng)目，是開源生態(tài)的一部分，盈利的目標(biāo)對(duì)于 Docker 來(lái)說(shuō)，屬于“強(qiáng)扭的瓜”。正如人際關(guān)系，從風(fēng)雨同舟到分道揚(yáng)鑣，甚至到反目成仇，這其中的轉(zhuǎn)折點(diǎn)，并非一兩次沖突，而是價(jià)值取向的背離。

他強(qiáng)調(diào)說(shuō)：“總體來(lái)說(shuō)，Docker 的弱勢(shì)來(lái)自于公司的盈利、技術(shù)應(yīng)用面兩方面，但如果談 Docker 的消亡，還為時(shí)過(guò)早。因?yàn)?Docker 本身也是一系列技術(shù)模塊的組合體系，而非一個(gè)東西。”

王新勇也認(rèn)為 Docker 技術(shù)（或者說(shuō) Moby 項(xiàng)目）和 Docker 公司得分開看待。短時(shí)間內(nèi)，Moby 項(xiàng)目不會(huì)消亡，會(huì)使用 Docker 命令可能會(huì)成為一個(gè)開發(fā)人員的必備技能，畢竟技術(shù)的慣性是很強(qiáng)大的。至于 Docker 公司，就算處境不樂(lè)觀，應(yīng)該也是不影響Docker 技術(shù)本身的，畢竟其背后還有強(qiáng)大的開源社區(qū)。

云原生技術(shù)的未來(lái)

近幾年，云原生技術(shù)發(fā)展速度很快，“Kubernetes 1.20 版本中棄用 Docker 支持”可能只是其中很小的一段插曲，畢竟在云原生的全局圖中，運(yùn)行時(shí)只占很小的一部分，而且又是比較標(biāo)準(zhǔn)化的部分。

“從云原生的角度來(lái)看 Kubernetes 棄用 Docker，其實(shí)是件好事，”楊明越表示：“Docker 已經(jīng)是個(gè)商業(yè)化產(chǎn)品了，如果能找到一個(gè)開源替代品，對(duì)整個(gè)技術(shù)的發(fā)展會(huì)更有益處。”那么，誰(shuí)將會(huì)代替 Docker 成為云原生技術(shù)的“新勢(shì)力”呢？在我們的采訪中，多位老師表示很看好 Podman。

Podman（Pod Manager）是一個(gè)由 RedHat 公司推出的容器管理工具，其定位就是 Docker 的替代品，在使用上與 Docker 的體驗(yàn)類似。Podman 源于 CRI-O 項(xiàng)目，可以直接訪問(wèn) OCI 的實(shí)現(xiàn)（如 runC），流程比 Docker 要短。

為什么說(shuō) Podman 是比 Docker 更先進(jìn)的存在呢？曉川表示：“首先，Docker 已經(jīng)是商業(yè)化的產(chǎn)品，而 podman 是個(gè)開源產(chǎn)品，在以開源為主的云原生技術(shù)體系中更容易得到推廣和應(yīng)用；其次，Docker 在實(shí)現(xiàn) CRI 時(shí)，需要一個(gè)守護(hù)進(jìn)程，并且以 root 來(lái)運(yùn)行，這就帶來(lái)了安全隱患，而 podman 不需要，可以直接通過(guò) OCI runtime（默認(rèn)也是 runc）來(lái)啟動(dòng)容器。”

Docker 與 Podman 的區(qū)別
由于 podman 的定位是 Docker 的替代品，因此在使用習(xí)慣方面也與 Docker 十分類似。

從系統(tǒng)構(gòu)建者角度看，podman 默認(rèn)軟件與 Docker 的區(qū)別不大，只是在進(jìn)程模型、進(jìn)程關(guān)系方面有所區(qū)別，例如關(guān)聯(lián)進(jìn)程的調(diào)試方面、進(jìn)程的樹狀結(jié)構(gòu)查看等等，而且總體來(lái)看，podman 要比 Docker 簡(jiǎn)單；從使用者角度看，podman 與 Docker 的命令基本兼容，包括容器運(yùn)行時(shí)、本地鏡像、鏡像倉(cāng)庫(kù)等。因此，podman 命令行工具與 docker 類似，比如構(gòu)建鏡像、啟停容器等，甚至可以通過(guò) alias docker=podman 可以進(jìn)行替換，即便使用了 podman，仍然可以使用 docker.io 作為鏡像倉(cāng)庫(kù)。

除了 Kubernetes，RHEL 7 同樣官方也不支持 Docker，只為容器環(huán)境提供 Podman、Buildah 以及 CRI-O。

采訪嘉賓：

楊明越，現(xiàn)從事分布式系統(tǒng)、云架構(gòu)方面工作，具有全方位的技術(shù)，曾任新興互聯(lián)網(wǎng)公司（BAT）的主任架構(gòu)師，世界頂級(jí)芯片公司的 OS 技術(shù)專家，前 Top2 通訊公司高級(jí)工程師。

王新勇，網(wǎng)易數(shù)帆資深架構(gòu)師，網(wǎng)易輕舟容器平臺(tái) NCS 負(fù)責(zé)人。

曉川，曾在 RedHat 任產(chǎn)品測(cè)試開發(fā)工程師，具有多年 Docker 容器、K8s、Linux 和 Python 方面的經(jīng)驗(yàn)，在 OpenShift 從事 PaaS 平臺(tái)比較前沿的技術(shù)項(xiàng)目。

作者 | Tina、田曉旭
采訪嘉賓 | 楊明越、王新勇、曉川
轉(zhuǎn)載自InfoQ