K8s棄用Docker

邰芷卉

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

兩年過去了，雖然K8s 1.24已經實現了“棄用Docker”的目標，但很多人似乎對這一點還不是很清楚。所以這里就來聊聊這個話題。

容器運行時接口（CRI）

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

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

快進到2016年，CNCF成立一年，K8s也發布了1.0版本，可以正式用于生產環境。這些都表明K8s已經長大了。

于是宣布加入CNCF，成為第一個CNCF托管項目，它想利用基金會的力量聯合其他廠商來“打倒”Docker。

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

但此時Docker已經非常成熟，市場的慣性也非常強。各大云廠商不可能一下子全部替換掉Docker。因此，K8s只能同時提供一種“折中”的方案，在kubelet和Docker之間增加一個“適配器”，將Docker的接口轉換為CRI兼容的接口。因為這個“適配器”夾在kubeletDocker和Docker之間，所以形象地被稱為shim，意思是“墊片”。

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

Containerd

面對挑戰，Docker采取了“斷臂求生”的策略，推動自身重構，將原有單一架構的Docker Engine拆分成多個模塊，其中Docker daemon部分捐贈給CNCF，containerd形成。

作為CNCF的托管項目，containerd必須符合CRI標準。但是由于很多原因，Docker只是containerd在Docker Engine中調用，對外的接口保持不變，也就是說不兼容CRI。

由于Docker的“固執”，此時K8s中有2條調用鏈：

使用CRI接口調用dockershim，然后dockershim調用Docker，Docker再去containerd操作容器；

使用CRI接口直接調用containerd操作容器。

顯然，因為containerd是用來管理容器的，所以這2個調用鏈的最終效果是完全一樣的，但是第二種方法去掉了dockershim和Docker Engine這2個環節，更加簡潔明性能也更好。

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

棄用Docker

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

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

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

“為什么K8s會這樣對待Docker？”

“之前對Docker的投資會歸零嗎？現有的大量鏡像怎么辦？”

其實，如果了解了上面提到的這2個項目CRI，containerd你就會知道，K8s的這一舉動并不奇怪，一切都是“自然”的：其實只是“棄用dockershim”，也就是dockershim搬出kubelet，并不是“棄用Docker”的軟件產品。

因此，“棄用Docker”對K8s和Docker的影響不大，因為它們都已經將底層改為開源containerd，原有的Docker鏡像和容器仍然可以正常運行。唯一的變化是K8s繞過了Docker，直接調用Docker內部的containerd。

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

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

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

從此，Kubernetes與Docker徹底“分道揚鑣”。

Docker的未來

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

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

首先，由于容器鏡像格式已經標準化（OCI規范，Open Container Initiative），Docker鏡像在K8s中仍然可以正常使用，不需要改變原有的開發測試和CI/CD流程。我們仍然可以拉取Docker Hub，或編寫一個Dockerfile來打包應用程序。

其次，Docker是一個完整的軟件產品線，它不僅僅是containerd，它還包括鏡像構建、分發、測試等很多服務，甚至連K8s都內置于Docker Desktop中。

就容器開發的便利性而言，Docker暫時還難以被取代。大多數云原生開發人員可以繼續在這個熟悉的環境中工作，使用Docker來開發在K8s中運行的應用程序。

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

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

對于初學者來說，Docker簡單易用，工具鏈完整，界面友好，市面上很難找到與之相媲美的軟件，應該說是入門級學習容器技術和云原生的上上選擇。