一句話(huà)總結(jié)：Docker只是容器的一種，它面向的是單體，K8S可以管理多種容器，它面向的是集群，Docker可以作為一種容器方案被K8S管理。下文繼續(xù)具體介紹。

1、容器的核心概念

介紹這幾個(gè)核心概念：OCI、CR、Runc、Containerd、CRI。

1.1、容器運(yùn)行規(guī)范

容器運(yùn)行規(guī)范OCI（Open Container Initiative）即開(kāi)放的容器運(yùn)行時(shí)規(guī)范，定義了鏡像和容器運(yùn)行時(shí)的規(guī)范。

容器鏡像規(guī)范：該規(guī)范的目標(biāo)是創(chuàng)建可互操作的工具，用于構(gòu)建、傳輸和準(zhǔn)備運(yùn)行的容器鏡像。

容器運(yùn)行時(shí)規(guī)范：該規(guī)范用于定義容器的配置、執(zhí)行環(huán)境和生命周期。

1.2、容器運(yùn)行時(shí)

容器運(yùn)行時(shí)（Container Runtime）負(fù)責(zé)以下工作：拉取鏡像、提取鏡像到文件系統(tǒng)、為容器準(zhǔn)備掛載點(diǎn)、從容器鏡像中設(shè)置元數(shù)據(jù)以確保容器按預(yù)期運(yùn)行、提醒內(nèi)核為該容器分配某種隔離、提醒內(nèi)核為該容器分配資源限制、調(diào)用系統(tǒng)指令啟動(dòng)容器等。

容器運(yùn)行時(shí)的有如下方案：Containerd、CRI-O 、Kata、Virtlet等等。

1.3、RunC

RunC （Run Container）是從 Docker 的 libcontainer 中遷移而來(lái)的，實(shí)現(xiàn)了容器啟停、資源隔離等功能。Docker將RunC捐贈(zèng)給 OCI 作為OCI 容器運(yùn)行時(shí)標(biāo)準(zhǔn)的參考實(shí)現(xiàn)。

RunC是一個(gè)基于OCI標(biāo)準(zhǔn)實(shí)現(xiàn)的一個(gè)輕量級(jí)容器運(yùn)行工具，用來(lái)創(chuàng)建和運(yùn)行容器。純從系統(tǒng)角度，Runc才是底層的容器運(yùn)行時(shí) 。

1.4、Containerd

Containerd是用來(lái)維持通過(guò)RunC創(chuàng)建的容器的運(yùn)行狀態(tài)。即RunC用來(lái)創(chuàng)建和運(yùn)行容器，containerd作為常駐進(jìn)程用來(lái)管理容器。containerd（container daemon）是一個(gè)daemon進(jìn)程用來(lái)管理和運(yùn)行容器，可以用來(lái)拉取/推送鏡像和管理容器的存儲(chǔ)和網(wǎng)絡(luò)。其中可以調(diào)用runc來(lái)創(chuàng)建和運(yùn)行容器。

很早之前的 Docker Engine 中就有了 Containerd，只不過(guò)現(xiàn)在是將 Containerd 從 Docker Engine 里分離出來(lái)，作為一個(gè)獨(dú)立的開(kāi)源項(xiàng)目，目標(biāo)是提供一個(gè)更加開(kāi)放、穩(wěn)定的容器運(yùn)行基礎(chǔ)設(shè)施。分離出來(lái)的Containerd 將具有更多的功能，涵蓋整個(gè)容器運(yùn)行時(shí)管理的所有需求，提供更強(qiáng)大的支持。

Containerd 是一個(gè)工業(yè)級(jí)標(biāo)準(zhǔn)的容器運(yùn)行時(shí)，它強(qiáng)調(diào)簡(jiǎn)單性、健壯性和可移植性，Containerd 可以負(fù)責(zé)干下面這些事情：

• 管理容器的生命周期（從創(chuàng)建容器到銷(xiāo)毀容器）
• 拉取/推送容器鏡像
• 存儲(chǔ)管理（管理鏡像及容器數(shù)據(jù)的存儲(chǔ)）
• 調(diào)用 runc 運(yùn)行容器（與 runc 等容器運(yùn)行時(shí)交互）
• 管理容器網(wǎng)絡(luò)接口及網(wǎng)絡(luò)

K8S自v1.24 起，已經(jīng)刪除了Dockershim ，使用Containerd作為容器運(yùn)行時(shí)。選擇 Containerd原因是，它的調(diào)用鏈更短，組件更少，更穩(wěn)定，占用節(jié)點(diǎn)資源更少。

1.5、Docker、Containerd、RunC的關(guān)系

三者關(guān)系，見(jiàn)下圖：

1.6、CRI

容器運(yùn)行時(shí)是 Kubernetes（K8S） 最重要的組件之一，負(fù)責(zé)管理鏡像和容器的生命周期。Kubelet 通過(guò) Container Runtime Interface (CRI) 與容器運(yùn)行時(shí)交互，以管理鏡像和容器。

CRI即容器運(yùn)行時(shí)接口，主要用來(lái)定義K8S與容器運(yùn)行時(shí)的API調(diào)用，kubelet通過(guò)CRI來(lái)調(diào)用容器運(yùn)行時(shí)，只要實(shí)現(xiàn)了CRI接口的容器運(yùn)行時(shí)就可以對(duì)接到K8S的kubelet組件。

2、Docker和K8S的關(guān)系

Docker和K8S本質(zhì)上都是創(chuàng)建容器的工具，Docker作用與單機(jī)，K8S作用與集群。

在單機(jī)的容器解決方案，首選Docker。隨著時(shí)代的發(fā)展，對(duì)系統(tǒng)的性能有了更高的要求，高可用、高并發(fā)都是基本要求。隨著要求變高的的同時(shí)，單機(jī)顯然性能就跟不上了，服務(wù)器集群管理就是發(fā)展趨勢(shì)，所以 Kubernetes 為代表的云原生技術(shù)強(qiáng)勢(shì)發(fā)展。

2.1、容器創(chuàng)建調(diào)用鏈路

Docker、Kubernetes、OCI、CRI-O、containerd、runc，他們是如何一起協(xié)作的呢，見(jiàn)下圖。

上圖所示為容器的調(diào)用鏈路。如圖我們看到的，只要是實(shí)現(xiàn)了CRI的容器運(yùn)行時(shí)就能夠被K8S采用。Containerd是通過(guò)CRI Plugin 來(lái)適配CRI的，而CRI-O則是為CRI量生打造。

我們還可以看到包括了Docker和K8S兩條主線(xiàn)，其中Docker主要是在面向單體應(yīng)用，K8S是用于集群。

2.2、關(guān)系

從上面的容器調(diào)用鏈路可以看到，對(duì)于Containerd 和 CRI-O我們非常清楚他們是干嘛的，但是對(duì)于Docker和K8S間的聯(lián)系我們還需要再來(lái)理一下。

如圖為K8S與Docker之間的聯(lián)系（包含K8S1.23版本在內(nèi)以及之前的版本），從K8S-1.24版本開(kāi)始將移除docker-shim模塊。下面繼續(xù)看看他們之間的小故事。

3、Dockershim的小故事

3.1、dockershim的由來(lái)

自 K8S - v1.24 起，Dockershim 已被刪除，這對(duì)K8S項(xiàng)目來(lái)說(shuō)是一個(gè)積極的舉措。

在 K8S 的早期，只支持一個(gè)容器運(yùn)行時(shí)，那個(gè)容器運(yùn)行時(shí)就是 Docker Engine。 那時(shí)并沒(méi)有其他的選擇。

隨著時(shí)間推移，我們開(kāi)始添加更多的容器運(yùn)行時(shí)，比如 rkt 和 hypernetes，很明顯 K8S 用戶(hù)希望選擇最適合他們的運(yùn)行時(shí)。因此，K8S 需要一種方法來(lái)允許K8S集群靈活地使用任何容器運(yùn)行時(shí)。

于是有了容器運(yùn)行時(shí)接口 (CRI) 的發(fā)布，CRI 的引入對(duì)K8S項(xiàng)目和K8S用戶(hù)來(lái)說(shuō)都很棒，但它引入了一個(gè)問(wèn)題：Docker Engine 作為容器運(yùn)行時(shí)的使用早于 CRI，所以Docker Engine 不兼容 CRI。

為了解決這個(gè)問(wèn)題，在 kubelet 組件中引入了一個(gè)小型軟件 shim (dockershim)，專(zhuān)門(mén)用于填補(bǔ) Docker Engine 和 CRI 之間的空白， 允許集群繼續(xù)使用 Docker Engine 作為容器運(yùn)行時(shí)。

3.2、dockershim的宿命

然而，這個(gè)小軟件 shim 從來(lái)沒(méi)有打算成為一個(gè)永久的解決方案。 多年來(lái)，它的存在給 kubelet 本身帶來(lái)了許多不必要的復(fù)雜性。由于這個(gè) shim，Docker 的一些集成實(shí)現(xiàn)不一致，導(dǎo)致維護(hù)人員的負(fù)擔(dān)增加。

總之，這樣的方式不但帶來(lái)了更高的復(fù)雜度，而且由于部件的增加也增加了不穩(wěn)定的因素，同時(shí)還增加了維護(hù)負(fù)擔(dān)，所以棄用dockershim是遲早的事。

總結(jié)：dockershim 一直都是 K8S 社區(qū)為了能讓 Docker 成為其支持的容器運(yùn)行時(shí)，所維護(hù)的一個(gè)兼容程序。 現(xiàn)在所謂的廢棄，也僅僅是 K8S 要放棄對(duì)現(xiàn)在代碼倉(cāng)庫(kù)中的 dockershim 的維護(hù)支持。以便K8S可以像剛開(kāi)始時(shí)計(jì)劃的那樣，僅負(fù)責(zé)維護(hù)其 CRI ，任何兼容 CRI 的容器運(yùn)行時(shí)，都可以作為 K8S 的 runtime。

3.3、流轉(zhuǎn)圖：

總結(jié)：本文講了容器的核心概念、Docker和K8S的關(guān)系、Dockershim的小故事，希望對(duì)你有幫助！