K8s棄用Docker

邰芷卉

如今很多人關(guān)注K8s棄用Docker的事，擔(dān)心現(xiàn)在學(xué)習(xí)Docker是否還值得，是不是該切換到containerd或其他運(yùn)行時(shí)。這些懷疑有一定的道理。兩年前，K8s發(fā)布“棄用Docker”的消息時(shí)，確實(shí)在社區(qū)引起了“軒然大波”，影響甚至蔓延到了社區(qū)之外，K8s發(fā)表了好幾篇博客來重復(fù)解釋原因。

兩年過去了，雖然K8s 1.24已經(jīng)實(shí)現(xiàn)了“棄用Docker”的目標(biāo)，但很多人似乎對(duì)這一點(diǎn)還不是很清楚。所以這里就來聊聊這個(gè)話題。

容器運(yùn)行時(shí)接口（CRI）

要理解K8s為何“棄用Docker”，我們得回顧一下K8s的發(fā)展史。

2014年，Docker正處于鼎盛時(shí)期，而K8s剛剛誕生。雖然它得到了Google和Borg的支持，但它還是比較新。因此，K8s首先選擇支持Docker。

快進(jìn)到2016年，CNCF成立一年，K8s也發(fā)布了1.0版本，可以正式用于生產(chǎn)環(huán)境。這些都表明K8s已經(jīng)長(zhǎng)大了。

于是宣布加入CNCF，成為第一個(gè)CNCF托管項(xiàng)目，它想利用基金會(huì)的力量聯(lián)合其他廠商來“打倒”Docker。

在2016年底的1.5版本中，K8s引入了新的接口標(biāo)準(zhǔn)：CRI（Container Runtime Interface）容器運(yùn)行時(shí)接口。CRI使用ProtoBufferandgPRC來指定kubelet應(yīng)該如何調(diào)用容器運(yùn)行以管理容器和鏡像，但這是一組與以前的Docker調(diào)用完全不兼容的新接口。顯然它不想再和Docker綁定，在底層允許訪問其他容器技術(shù)（如rkt、kata等），感覺可以隨時(shí)“踢開”Docker。

但此時(shí)Docker已經(jīng)非常成熟，市場(chǎng)的慣性也非常強(qiáng)。各大云廠商不可能一下子全部替換掉Docker。因此，K8s只能同時(shí)提供一種“折中”的方案，在kubelet和Docker之間增加一個(gè)“適配器”，將Docker的接口轉(zhuǎn)換為CRI兼容的接口。因?yàn)檫@個(gè)“適配器”夾在kubeletDocker和Docker之間，所以形象地被稱為shim，意思是“墊片”。

有了CRI和shim，雖然K8s仍然使用Docker作為底層運(yùn)行時(shí)，但它也具備了與Docker解耦的條件，從而拉開了“棄用Docker”大戲的帷幕。

Containerd

面對(duì)挑戰(zhàn)，Docker采取了“斷臂求生”的策略，推動(dòng)自身重構(gòu)，將原有單一架構(gòu)的Docker Engine拆分成多個(gè)模塊，其中Docker daemon部分捐贈(zèng)給CNCF，containerd形成。

作為CNCF的托管項(xiàng)目，containerd必須符合CRI標(biāo)準(zhǔn)。但是由于很多原因，Docker只是containerd在Docker Engine中調(diào)用，對(duì)外的接口保持不變，也就是說不兼容CRI。

由于Docker的“固執(zhí)”，此時(shí)K8s中有2條調(diào)用鏈：

使用CRI接口調(diào)用dockershim，然后dockershim調(diào)用Docker，Docker再去containerd操作容器；

使用CRI接口直接調(diào)用containerd操作容器。

顯然，因?yàn)閏ontainerd是用來管理容器的，所以這2個(gè)調(diào)用鏈的最終效果是完全一樣的，但是第二種方法去掉了dockershim和Docker Engine這2個(gè)環(huán)節(jié)，更加簡(jiǎn)潔明性能也更好。

2018年Kubernetes 1.10發(fā)布時(shí)，containerd也更新到1.1版本，正式與Kubernetes集成，并發(fā)表顯示一些性能測(cè)試的數(shù)據(jù)。從這些數(shù)據(jù)可以看出，相比當(dāng)時(shí)的Docker 18.03，containerd1.1Pod啟動(dòng)延遲降低了20 %左右，CPU使用率降低了68 %，內(nèi)存使用率降低了12 %，這樣可觀的性能提升對(duì)云廠商來說非常有誘惑力。

棄用Docker

2020年，K8s 1.20終于正式向Docker“宣戰(zhàn)”：kubelet將棄用Docker支持，并將在未來的版本中完全移除。但由于Docker幾乎已經(jīng)成為容器技術(shù)的代名詞，而且K8s也已經(jīng)使用Docker多年，該公告在傳播時(shí)很快“變味了”，“kubelet將棄用Docker支持”被簡(jiǎn)化為更吸人眼球的東西“K8s將棄用Docker”。

這自然引起了IT界的恐慌，“不明真相的群眾”紛紛表示震驚：

“用了這么久的Docker突然不能用了。”

“為什么K8s會(huì)這樣對(duì)待Docker？”

“之前對(duì)Docker的投資會(huì)歸零嗎？現(xiàn)有的大量鏡像怎么辦？”

其實(shí)，如果了解了上面提到的這2個(gè)項(xiàng)目CRI，containerd你就會(huì)知道，K8s的這一舉動(dòng)并不奇怪，一切都是“自然”的：其實(shí)只是“棄用dockershim”，也就是dockershim搬出kubelet，并不是“棄用Docker”的軟件產(chǎn)品。

因此，“棄用Docker”對(duì)K8s和Docker的影響不大，因?yàn)樗鼈兌家呀?jīng)將底層改為開源containerd，原有的Docker鏡像和容器仍然可以正常運(yùn)行。唯一的變化是K8s繞過了Docker，直接調(diào)用Docker內(nèi)部的containerd。

然而，還是會(huì)有一些影響。如果K8s直接使用containerd來操作容器，那么它就是獨(dú)立于Docker的工作環(huán)境，二者都無法訪問對(duì)方管理的容器和鏡像。換句話說，使用docker ps命令將不會(huì)看到K8s中運(yùn)行的容器。

這對(duì)一些人來說可能需要花一點(diǎn)時(shí)間來適應(yīng)并使用新工具crictl，但用于查看容器和鏡像的子命令仍然是相同的，例如ps，images等，其實(shí)不難適應(yīng)（如果你一直在用kubectl管理K8s，就沒有這個(gè)影響）。

K8s原本計(jì)劃用一年時(shí)間完成“棄用Docker”的工作，但它確實(shí)低估了Docker的基礎(chǔ)。1.23版本還是沒能移除dockershim，只好延期半年。最后，1.24版本從kubelet中刪除了dockershim的代碼。

從此，Kubernetes與Docker徹底“分道揚(yáng)鑣”。

Docker的未來

那么，Docker的未來會(huì)怎樣呢？云原生時(shí)代就沒有它的立足之地嗎？這個(gè)問題的答案顯然是否定的。

作為容器技術(shù)的奠基人，沒有人可以質(zhì)疑Docker的歷史地位。雖然K8s默認(rèn)不再綁定Docker，但Docker仍然可以與其他形式的K8s共存。

首先，由于容器鏡像格式已經(jīng)標(biāo)準(zhǔn)化（OCI規(guī)范，Open Container Initiative），Docker鏡像在K8s中仍然可以正常使用，不需要改變?cè)械拈_發(fā)測(cè)試和CI/CD流程。我們?nèi)匀豢梢岳ocker Hub，或編寫一個(gè)Dockerfile來打包應(yīng)用程序。

其次，Docker是一個(gè)完整的軟件產(chǎn)品線，它不僅僅是containerd，它還包括鏡像構(gòu)建、分發(fā)、測(cè)試等很多服務(wù)，甚至連K8s都內(nèi)置于Docker Desktop中。

就容器開發(fā)的便利性而言，Docker暫時(shí)還難以被取代。大多數(shù)云原生開發(fā)人員可以繼續(xù)在這個(gè)熟悉的環(huán)境中工作，使用Docker來開發(fā)在K8s中運(yùn)行的應(yīng)用程序。

同樣，雖然K8s不再包含dockershim，Docker已經(jīng)接管了這部分代碼并構(gòu)建了一個(gè)名為cri-dockerd的項(xiàng)目，該項(xiàng)目也同樣工作，將Docker Engine適配為CRI接口，這樣kubelet可以通過它再次操作Docker，就像它從來沒有發(fā)生過一樣。

總的來說，Docker雖然在容器編排大戰(zhàn)中敗下陣來，被K8s擠到了墻角，但依然具有很強(qiáng)的生命力。多年積累的眾多忠實(shí)用戶和大量應(yīng)用形象是其最大的資本和后盾，足以支持它在另一條不與K8s正面交鋒的道路上。

對(duì)于初學(xué)者來說，Docker簡(jiǎn)單易用，工具鏈完整，界面友好，市面上很難找到與之相媲美的軟件，應(yīng)該說是入門級(jí)學(xué)習(xí)容器技術(shù)和云原生的上上選擇。