1)Kubernetes與Docker
Docker是最早出現的那批容器引擎工具,所以它最早占領了市場。Kubernetes主要用來做容器編排,用來管理容器集群,是一個平臺。
Kubernetes要想去控制容器,就得借助容器引擎,在早期的Kubernetes版本里,除了選擇Docker作為容器引擎外,沒更好的選擇。所以早期的Kubernetes和Docker深深地綁定了在一起。由于Docker可以在沒有Kubernetes的情況下使用,而Kubernetes必須要有容器運行時(Docker引擎)才能進行編排。
這對于Kubernetes來說,絕對是一個非常大的隱患,這相當于是將自己命根子交給了別人,如果哪天Docker翻臉了,Kubernetes必然損失巨大。
好在,Kubernetes發展比Docker更加迅猛,勢頭遠遠蓋過了Docker,Kubernetes終于有資格自己決定做一些事情了。
2)CRI
為了解決隱患,Kubernetes在1.5版本里,引入了一個新的接口標準:CRI(Container Runtime Interface),它主要用來規定如何調用容器運行時來管理容器和鏡像,但這個接口標準和之前的Docker調用標準有不少差異,所以兩者完全不兼容。這意味著,Kubernetes可以撇開Docker,使用其它容器運行時(如rkt)。
由于Docker用戶非常龐大,Kubernetes也意識到了直接不兼容Docker會有許多不確定風險,當時,Kubernetes用了一個臨時方案,在Kubernetes和Docker中間開發了一個Dockershim,主要用來將Docker的接口標準轉換成CRI標準。
3)Containerd
Docker意識到Kubernetes的改變,為了迎合Kubernetes,將Docker Engine拆分成多個模塊,其中Docker Daemon部分也就是說Containerd捐獻給了CNCF。
所以,Containerd實際上是Docker引擎拆出來的一個模塊。
Containerd 作為 CNCF 的托管項目,自然是要符合 CRI 標準的。但當時的Docker 出于自己諸多原因的考慮,它只是在 Docker Engine 里調用了 containerd,外部的接口仍然保持不變,也就是說還不與 CRI 兼容。
在當時的Kubernetes版本里,有兩種方法調用容器:
第一種是用 CRI 調用 dockershim,然后 dockershim 調用 Docker,Docker 再走 containerd 去操作容器。
第二種是用 CRI 直接調用 containerd 去操作容器。
很明顯,第一種方法多了兩層調用,性能明顯不如第二種方法。所以Kubernetes決定將dockershim移除,所以也就不能直接使用Docker了,在外界看來就像是Kubernetes棄用了Docker。
4)棄用dockershim
2020年Kubernetes發布1.20版本時,對外聲明將在后續版本里(實際上是在22年的1.24版本里)移除dockershim,也就是取消對Docker的支持。當時,眾多吃瓜群眾理解錯了意思,認為成了Kubernetes棄用Docker。它實際上只是“棄用了 dockershim”這個小組件,也就是說把 dockershim 移出了 kubelet,并不是“棄用了 Docker”這個軟件產品。
這個舉措對Kubernetes和 Docker 來說都不會有什么太大的影響,因為他們兩個都早已經把下層都改成了開源的 containerd,原來的 Docker 鏡像和容器仍然會正常運行,唯一的變化就是 Kubernetes繞過了 Docker,直接調用 Docker 內部的 containerd 而已。
5)Kubernetes移除dockershim后對Docker的影響
雖然現在 Kubernetes 不再默認綁定 Docker,但 Docker 還是能夠以其他的形式與 Kubernetes 共存的。
首先,因為容器鏡像格式已經被標準化了(OCI 規范,Open Container Initiative),Docker 鏡像仍然可以在 Kubernetes 里正常使用,原來的開發測試、CI/CD 流程都不需要改動,我們仍然可以拉取 Docker Hub 上的鏡像,或者編寫 Dockerfile 來打包應用。
其次,Docker 是一個完整的軟件產品線,不止是 containerd,它還包括了鏡像構建、分發、測試等許多服務,甚至在 Docker Desktop 里還內置了 Kubernetes。單就容器開發的便利性來講,Docker 還是暫時難以被替代的,廣大云原生開發者可以在這個熟悉的環境里繼續工作,利用 Docker 來開發運行在 Kubernetes 里的應用。
再次,雖然 Kubernetes 已經不再包含 dockershim,但 Docker 公司卻把這部分代碼接管了過來,另建了一個叫 cri-dockerd的項目,作用也是一樣的,把 Docker Engine 適配成 CRI 接口,這樣 kubelet 就又可以通過它來操作 Docker 了,就仿佛是一切從未發生過。
綜合來看,Docker 雖然在容器編排戰爭里落敗,被 Kubernetes 排擠到了角落,但它仍然具有強韌的生命力,多年來積累的眾多忠實用戶和數量龐大的應用鏡像是它的最大資本和后盾,足以支持它在另一條不與 Kubernetes 正面交鋒的道路上走下去。而對于我們這些初學者來說,Docker 方便易用,具有完善的工具鏈和友好的交互界面,市面上很難找到能夠與它媲美的軟件了,應該說是入門學習容器技術和云原生的“不二之選”。
審核編輯:湯梓紅
-
容器
+關注
關注
0文章
495瀏覽量
22060 -
鏡像
+關注
關注
0文章
164瀏覽量
10707 -
Docker
+關注
關注
0文章
457瀏覽量
11846 -
kubernetes
+關注
關注
0文章
224瀏覽量
8712
原文標題:Docker、Containerd和Kubernetes之間的關系
文章出處:【微信號:aming_linux,微信公眾號:阿銘linux】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論