1)Kubernetes與Docker

Docker是最早出現(xiàn)的那批容器引擎工具，所以它最早占領(lǐng)了市場。Kubernetes主要用來做容器編排，用來管理容器集群，是一個平臺。

Kubernetes要想去控制容器，就得借助容器引擎，在早期的Kubernetes版本里，除了選擇Docker作為容器引擎外，沒更好的選擇。所以早期的Kubernetes和Docker深深地綁定了在一起。由于Docker可以在沒有Kubernetes的情況下使用，而Kubernetes必須要有容器運(yùn)行時(Docker引擎)才能進(jìn)行編排。

這對于Kubernetes來說，絕對是一個非常大的隱患，這相當(dāng)于是將自己命根子交給了別人，如果哪天Docker翻臉了，Kubernetes必然損失巨大。

好在，Kubernetes發(fā)展比Docker更加迅猛，勢頭遠(yuǎn)遠(yuǎn)蓋過了Docker，Kubernetes終于有資格自己決定做一些事情了。

2)CRI

為了解決隱患，Kubernetes在1.5版本里，引入了一個新的接口標(biāo)準(zhǔn)：CRI(Container Runtime Interface)，它主要用來規(guī)定如何調(diào)用容器運(yùn)行時來管理容器和鏡像，但這個接口標(biāo)準(zhǔn)和之前的Docker調(diào)用標(biāo)準(zhǔn)有不少差異，所以兩者完全不兼容。這意味著，Kubernetes可以撇開Docker，使用其它容器運(yùn)行時(如rkt)。

由于Docker用戶非常龐大，Kubernetes也意識到了直接不兼容Docker會有許多不確定風(fēng)險(xiǎn)，當(dāng)時，Kubernetes用了一個臨時方案，在Kubernetes和Docker中間開發(fā)了一個Dockershim，主要用來將Docker的接口標(biāo)準(zhǔn)轉(zhuǎn)換成CRI標(biāo)準(zhǔn)。

3)Containerd

Docker意識到Kubernetes的改變，為了迎合Kubernetes，將Docker Engine拆分成多個模塊，其中Docker Daemon部分也就是說Containerd捐獻(xiàn)給了CNCF。

所以，Containerd實(shí)際上是Docker引擎拆出來的一個模塊。

Containerd 作為 CNCF 的托管項(xiàng)目，自然是要符合 CRI 標(biāo)準(zhǔn)的。但當(dāng)時的Docker 出于自己諸多原因的考慮，它只是在 Docker Engine 里調(diào)用了 containerd，外部的接口仍然保持不變，也就是說還不與 CRI 兼容。

在當(dāng)時的Kubernetes版本里，有兩種方法調(diào)用容器：

第一種是用 CRI 調(diào)用 dockershim，然后 dockershim 調(diào)用 Docker，Docker 再走 containerd 去操作容器。

第二種是用 CRI 直接調(diào)用 containerd 去操作容器。

很明顯，第一種方法多了兩層調(diào)用，性能明顯不如第二種方法。所以Kubernetes決定將dockershim移除，所以也就不能直接使用Docker了，在外界看來就像是Kubernetes棄用了Docker。

4)棄用dockershim

2020年Kubernetes發(fā)布1.20版本時，對外聲明將在后續(xù)版本里(實(shí)際上是在22年的1.24版本里)移除dockershim，也就是取消對Docker的支持。當(dāng)時，眾多吃瓜群眾理解錯了意思，認(rèn)為成了Kubernetes棄用Docker。它實(shí)際上只是“棄用了 dockershim”這個小組件，也就是說把 dockershim 移出了 kubelet，并不是“棄用了 Docker”這個軟件產(chǎn)品。

這個舉措對Kubernetes和 Docker 來說都不會有什么太大的影響，因?yàn)樗麄儍蓚€都早已經(jīng)把下層都改成了開源的 containerd，原來的 Docker 鏡像和容器仍然會正常運(yùn)行，唯一的變化就是 Kubernetes繞過了 Docker，直接調(diào)用 Docker 內(nèi)部的 containerd 而已。

5)Kubernetes移除dockershim后對Docker的影響

雖然現(xiàn)在 Kubernetes 不再默認(rèn)綁定 Docker，但 Docker 還是能夠以其他的形式與 Kubernetes 共存的。

首先，因?yàn)槿萜麋R像格式已經(jīng)被標(biāo)準(zhǔn)化了(OCI 規(guī)范，Open Container Initiative)，Docker 鏡像仍然可以在 Kubernetes 里正常使用，原來的開發(fā)測試、CI/CD 流程都不需要改動，我們?nèi)匀豢梢岳?Docker Hub 上的鏡像，或者編寫 Dockerfile 來打包應(yīng)用。

其次，Docker 是一個完整的軟件產(chǎn)品線，不止是 containerd，它還包括了鏡像構(gòu)建、分發(fā)、測試等許多服務(wù)，甚至在 Docker Desktop 里還內(nèi)置了 Kubernetes。單就容器開發(fā)的便利性來講，Docker 還是暫時難以被替代的，廣大云原生開發(fā)者可以在這個熟悉的環(huán)境里繼續(xù)工作，利用 Docker 來開發(fā)運(yùn)行在 Kubernetes 里的應(yīng)用。

再次，雖然 Kubernetes 已經(jīng)不再包含 dockershim，但 Docker 公司卻把這部分代碼接管了過來，另建了一個叫 cri-dockerd的項(xiàng)目，作用也是一樣的，把 Docker Engine 適配成 CRI 接口，這樣 kubelet 就又可以通過它來操作 Docker 了，就仿佛是一切從未發(fā)生過。

綜合來看，Docker 雖然在容器編排戰(zhàn)爭里落敗，被 Kubernetes 排擠到了角落，但它仍然具有強(qiáng)韌的生命力，多年來積累的眾多忠實(shí)用戶和數(shù)量龐大的應(yīng)用鏡像是它的最大資本和后盾，足以支持它在另一條不與 Kubernetes 正面交鋒的道路上走下去。而對于我們這些初學(xué)者來說，Docker 方便易用，具有完善的工具鏈和友好的交互界面，市面上很難找到能夠與它媲美的軟件了，應(yīng)該說是入門學(xué)習(xí)容器技術(shù)和云原生的“不二之選”。

審核編輯：湯梓紅