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

1、容器的核心概念

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

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

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

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

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

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

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

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

1.3、RunC

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

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

1.4、Containerd

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

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

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

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

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

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

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

1.6、CRI

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

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

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

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

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

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

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

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

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

2.2、關(guān)系

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

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

3、Dockershim的小故事

3.1、dockershim的由來

自 K8S - v1.24 起，Dockershim 已被刪除，這對K8S項(xiàng)目來說是一個積極的舉措。

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

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

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

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

3.2、dockershim的宿命

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

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

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

3.3、流轉(zhuǎn)圖：

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