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

1、容器的核心概念

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

1.1、容器運行規范

容器運行規范OCI（Open Container Initiative）即開放的容器運行時規范，定義了鏡像和容器運行時的規范。

容器鏡像規范：該規范的目標是創建可互操作的工具，用于構建、傳輸和準備運行的容器鏡像。

容器運行時規范：該規范用于定義容器的配置、執行環境和生命周期。

1.2、容器運行時

容器運行時（Container Runtime）負責以下工作：拉取鏡像、提取鏡像到文件系統、為容器準備掛載點、從容器鏡像中設置元數據以確保容器按預期運行、提醒內核為該容器分配某種隔離、提醒內核為該容器分配資源限制、調用系統指令啟動容器等。

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

1.3、RunC

RunC （Run Container）是從 Docker 的 libcontainer 中遷移而來的，實現了容器啟停、資源隔離等功能。Docker將RunC捐贈給 OCI 作為OCI 容器運行時標準的參考實現。

RunC是一個基于OCI標準實現的一個輕量級容器運行工具，用來創建和運行容器。純從系統角度，Runc才是底層的容器運行時 。

1.4、Containerd

Containerd是用來維持通過RunC創建的容器的運行狀態。即RunC用來創建和運行容器，containerd作為常駐進程用來管理容器。containerd（container daemon）是一個daemon進程用來管理和運行容器，可以用來拉取/推送鏡像和管理容器的存儲和網絡。其中可以調用runc來創建和運行容器。

很早之前的 Docker Engine 中就有了 Containerd，只不過現在是將 Containerd 從 Docker Engine 里分離出來，作為一個獨立的開源項目，目標是提供一個更加開放、穩定的容器運行基礎設施。分離出來的Containerd 將具有更多的功能，涵蓋整個容器運行時管理的所有需求，提供更強大的支持。

Containerd 是一個工業級標準的容器運行時，它強調簡單性、健壯性和可移植性，Containerd 可以負責干下面這些事情：

• 管理容器的生命周期（從創建容器到銷毀容器）
• 拉取/推送容器鏡像
• 存儲管理（管理鏡像及容器數據的存儲）
• 調用 runc 運行容器（與 runc 等容器運行時交互）
• 管理容器網絡接口及網絡

K8S自v1.24 起，已經刪除了Dockershim ，使用Containerd作為容器運行時。選擇 Containerd原因是，它的調用鏈更短，組件更少，更穩定，占用節點資源更少。

1.5、Docker、Containerd、RunC的關系

三者關系，見下圖：

1.6、CRI

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

CRI即容器運行時接口，主要用來定義K8S與容器運行時的API調用，kubelet通過CRI來調用容器運行時，只要實現了CRI接口的容器運行時就可以對接到K8S的kubelet組件。

2、Docker和K8S的關系

Docker和K8S本質上都是創建容器的工具，Docker作用與單機，K8S作用與集群。

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

2.1、容器創建調用鏈路

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

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

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

2.2、關系

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

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

3、Dockershim的小故事

3.1、dockershim的由來

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

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

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

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

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

3.2、dockershim的宿命

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

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

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

3.3、流轉圖：

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