一句話總結(jié)docker與K8S的關系

作者：不焦躁的程序員 2023-09-06 15:23:30

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

創(chuàng)新互聯(lián)公司技術(shù)團隊十多年來致力于為客戶提供成都網(wǎng)站設計、做網(wǎng)站、品牌網(wǎng)站建設、成都全網(wǎng)營銷推廣、搜索引擎SEO優(yōu)化等服務。經(jīng)過多年發(fā)展，公司擁有經(jīng)驗豐富的技術(shù)團隊，先后服務、推廣了上千家網(wǎng)站，包括各類中小企業(yè)、企事單位、高校等機構(gòu)單位。

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

1、容器的核心概念

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

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

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

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

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

1.2、容器運行時

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

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

1.3、RunC

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

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

1.4、Containerd

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

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

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

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

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

1.5、Docker、Containerd、RunC的關系

三者關系，見下圖：

1.6、CRI

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

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

2、Docker和K8S的關系

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

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

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

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

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

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

2.2、關系

從上面的容器調(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項目來說是一個積極的舉措。

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

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

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

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

3.2、dockershim的宿命

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

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

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

3.3、流轉(zhuǎn)圖：

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

新聞名稱：一句話總結(jié)Docker與K8S的關系
網(wǎng)頁路徑：http://m.5511xx.com/article/codgcpg.html