1)Kubernetes與Docker

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

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

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

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

2)CRI

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

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

3)Containerd

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

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

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

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

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

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

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

4)棄用dockershim

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

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

5)Kubernetes移除dockershim后對(duì)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 里正常使用，原來(lái)的開發(fā)測(cè)試、CI/CD 流程都不需要改動(dòng)，我們?nèi)匀豢梢岳?Docker Hub 上的鏡像，或者編寫 Dockerfile 來(lái)打包應(yīng)用。

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

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

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

審核編輯：湯梓紅