這篇zhe pian首先接觸這個(gè)概念是k8s官方文檔中https://kubernetes.io/zh/docs/setup/production-environment/container-runtimes/，開始時(shí)候很蒙蔽，之前搭建k8s集群時(shí)也沒用到CRI啊。后來讀到下面這邊文章，大概明白了

Kubernetes 容器運(yùn)行時(shí)演進(jìn)

1. Kubernetes 簡介
2. Kubelet 架構(gòu)
3. 容器運(yùn)行時(shí)演進(jìn)過程
4. 容器運(yùn)行時(shí)接口（CRI）
   1. CRI 接口
   2. Streaming API
   3. 容器運(yùn)行時(shí)實(shí)例
5. 多租戶
6. CRI Tools
7. 未來展望
   1. 多容器運(yùn)行時(shí)
   2. 無服務(wù)器容器服務(wù)

注：本文是我在中國云原生大會(huì)（CEUC 2018） 上同名演講的文字整理。

Kubernetes 已經(jīng)成為容器編排調(diào)度領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，其優(yōu)良的架構(gòu)不僅保證了豐富的容器編排調(diào)度功能，同時(shí)也提供了各個(gè)層次的擴(kuò)展接口以滿足用戶的定制化需求。其中，容器運(yùn)行時(shí)作為 Kubernetes 管理和運(yùn)行容器的關(guān)鍵組件，當(dāng)然也提供了簡便易用的擴(kuò)展接口，也就是 CRI（Container Runtime Interface）。CRI 促進(jìn)了容器運(yùn)行時(shí)社區(qū)的繁榮，也為強(qiáng)隔離、多租戶等復(fù)雜的場景帶來更多的選擇。

本文將介紹 Kubernetes 容器運(yùn)行時(shí)的演進(jìn)過程、如何借助繁榮的容器運(yùn)行時(shí)社區(qū)滿足各種復(fù)雜的多租戶場景以及未來的發(fā)展展望。主要內(nèi)容包括四個(gè)部分：

• 首先是簡單介紹一下 Kubernetes 的架構(gòu)，特別是 Kubelet 架構(gòu)，依次確定容器運(yùn)行時(shí)在 Kubernetes 整個(gè)架構(gòu)中的位置和作用
• 然后介紹 Kubernetes 發(fā)展過程中，容器運(yùn)行時(shí)的演進(jìn)過程
• 接著第三部分介紹容器運(yùn)行時(shí)接口的設(shè)計(jì)以及實(shí)現(xiàn)新的容器運(yùn)行時(shí)的方法
• 最后看一下 Kubernetes 社區(qū)在容器運(yùn)行時(shí)的發(fā)展展望

Kubernetes 簡介

首先來看第一部分，介紹下Kubernetes 的基本原理，并梳理容器運(yùn)行時(shí)在 Kubernetes架構(gòu)中的位置。

我們知道，Kubernetes是谷歌開源的容器集群管理系統(tǒng)，它的發(fā)展非常迅速，已經(jīng)成為最流行和最活躍的容器編排系統(tǒng)。它提供了完善的集群管理能力，包括多層次的安全防護(hù)和準(zhǔn)入機(jī)制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊和服務(wù)發(fā)現(xiàn)機(jī)制、內(nèi)建負(fù)載均衡器、故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動(dòng)升級(jí)和在線擴(kuò)容、可擴(kuò)展的資源自動(dòng)調(diào)度機(jī)制、多粒度的資源配額管理能力。

從架構(gòu)上來說，Kubernetes 的組件可以分為 Master 和 Node 兩部分，其中 Master 是整個(gè)集群的大腦，所有的編排、調(diào)度、API 訪問等都由 Master 來負(fù)責(zé)。具體的來說，Master 包括以下幾個(gè)組件：

• etcd 保存了整個(gè)集群的狀態(tài)。
• kube-apiserver 提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API 注冊和發(fā)現(xiàn)等機(jī)制。并且無論是集群內(nèi)部還是外部的組件，都必須通過API Server來訪問數(shù)據(jù)。
• kube-controller-manager 負(fù)責(zé)維護(hù)集群的狀態(tài)，包括很多資源的控制器，是保證 Kubernetes 聲明式 API 工作的大腦，比如故障檢測、自動(dòng)擴(kuò)展、滾動(dòng)更新等。
• kube-scheduler 負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將 Pod 調(diào)度到相應(yīng)的 Node 上；

而 Node 則是負(fù)責(zé)運(yùn)行具體的容器，并為容器提供存儲(chǔ)、網(wǎng)絡(luò)等必要的功能：

• kubelet 負(fù)責(zé)維持容器的生命周期，同時(shí)也負(fù)責(zé) Volume（CSI）和網(wǎng)絡(luò)（CNI）的管理；
• Container runtime 負(fù)責(zé)鏡像管理以及 Pod 和容器的真正運(yùn)行（CRI），默認(rèn)的容器運(yùn)行時(shí)為 Docker；
• kube-proxy 負(fù)責(zé)為 Service 提供 cluster 內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡
• Network plugin 負(fù)責(zé)為容器配置網(wǎng)絡(luò)

image-20181014230247199

Kubernetes 除了這些核心的組件以外，還有很多豐富的功能，而這些額外的功能都是通過“Addon”的方式來部署的。比如 kube-dns 和 metrics-server 等，都是以容器的方式部署在集群里面，并提供 API 給其他組件調(diào)用。

Kubelet 架構(gòu)

Kubelet 負(fù)責(zé)維持容器的生命周期，同時(shí)也配合 kube-controller-manager 管理容器的存儲(chǔ)卷，并配合 CNI 管理容器的網(wǎng)絡(luò)。接下來，我們再來仔細(xì)看看 Kubelet 的架構(gòu)。

image

Kubelet 也是有很多組件構(gòu)成，包括

• Kubelet Server 對外提供 API，供 kube-apiserver、metrics-server 等服務(wù)調(diào)用。比如 kubectl exec 時(shí)需要通過 Kubelet API /exec/{token} 與容器進(jìn)行交互。
• Container Manager 管理容器的各種資源，比如 cgroups、QoS、cpuset、device 等。
• Volume Manager 管理容器的存儲(chǔ)卷，比如格式化資盤、掛載到 Node 本地、最后再將掛載路徑傳給容器。
• Eviction 負(fù)責(zé)容器的驅(qū)逐，比如在資源不足時(shí)驅(qū)逐優(yōu)先級(jí)低的容器，保證高優(yōu)先級(jí)容器的運(yùn)行。
• cAdvisor 負(fù)責(zé)為容器提供 metrics
• Metrics 和 stats 提供容器和節(jié)點(diǎn)的度量數(shù)據(jù)，比如 metrics-server 通過 /stats/summary 提取的度量數(shù)據(jù)是 HPA 自動(dòng)擴(kuò)展的依據(jù)。
• 再向下呢就是 Generic Runtime Manager，這是容器運(yùn)行時(shí)的管理者，負(fù)責(zé)于 CRI 交互，完成容器和鏡像的管理
• 在 CRI 之下，包括兩種容器運(yùn)行時(shí)的實(shí)現(xiàn)
  • 一個(gè)是內(nèi)置的 dockershim，實(shí)現(xiàn)了 docker 容器引擎的支持以及 CNI 網(wǎng)絡(luò)插件（包括 kubenet）的支持
  • 另一個(gè)就是外部的容器運(yùn)行時(shí)，用來支持 runc、containerd、gvisor 等外部容器運(yùn)行時(shí)

Kubelet 通過 CRI 接口跟外部容器運(yùn)行時(shí)交互，它包括

• CRI Server，這是 CRI gRPC server，監(jiān)聽在 unix socket 上面
• Streaming Server，提供 streaming API，包括 Exec、Attach、Port Forward
• 容器和鏡像的管理，比如拉取鏡像、創(chuàng)建和啟動(dòng)容器等
• CNI 網(wǎng)絡(luò)插件的支持，用于給容器配置網(wǎng)絡(luò)
• 最后是容器引擎的管理，比如支持 runc 、containerd 或者支持多個(gè)容器引擎

這樣，Kubernetes 中的容器運(yùn)行時(shí)按照不同的功能就可以分為三個(gè)部分：

• 第一個(gè)是 Kubelet 中容器運(yùn)行時(shí)的管理，它通過 CRI 管理容器和鏡像
• 第二個(gè)是容器運(yùn)行時(shí)接口，是 Kubelet 與外部容器運(yùn)行時(shí)的通信接口
• 第三個(gè)是具體的容器運(yùn)行時(shí)實(shí)現(xiàn)，包括 Kubelet 內(nèi)置的 dockershim 以及外部的容器運(yùn)行時(shí)（如 cri-o、cri-containerd、frakti等）

這樣的話，我們就可以基于這三個(gè)不同部分來看一看容器運(yùn)行的演進(jìn)過程。

容器運(yùn)行時(shí)演進(jìn)過程

image-20181014230405547

容器運(yùn)行時(shí)的演進(jìn)可以分為三個(gè)階段：

首先，在 Kubernetes v1.5 之前，Kubelet 內(nèi)置了 Docker 和 rkt 的支持，并且通過 CNI 網(wǎng)絡(luò)插件給它們配置容器網(wǎng)絡(luò)。這個(gè)階段的用戶如果需要自定義運(yùn)行時(shí)的功能是比較痛苦的，需要修改 Kubelet 的代碼，并且很有可能這些修改無法推到上游社區(qū)。這樣，還需要維護(hù)一個(gè)自己的 fork 分支，維護(hù)和升級(jí)都非常麻煩。

第二階段，不同用戶實(shí)現(xiàn)的容器運(yùn)行時(shí)各有所長，許多用戶都希望Kubernetes支持更多的運(yùn)行時(shí)。于是，從v1.5 開始增加了 CRI 接口，通過容器運(yùn)行時(shí)的抽象層消除了這些障礙，使得無需修改 Kubelet 就可以支持運(yùn)行多種容器運(yùn)行時(shí)。CRI 接口包括了一組 Protocol Buffer、gRPC API 、用于 streaming 接口的庫以及用于調(diào)試和驗(yàn)證的一系列工具等。在此階段，內(nèi)置的 Docker 實(shí)現(xiàn)也逐步遷移到了 CRI 的接口之下。但此時(shí) rkt 還未完全遷移，這是因?yàn)?rkt 遷移 CRI 的過程將在獨(dú)立的 repository 完成，方便其維護(hù)和管理。

第三階段，從 v1.11 開始，Kubelet 內(nèi)置的 rkt 代碼刪除，CNI 的實(shí)現(xiàn)遷移到 dockershim 之內(nèi)。這樣，除了 docker 之外，其他的容器運(yùn)行時(shí)都通過 CRI 接入。外部的容器運(yùn)行時(shí)一般稱為 CRI Shim，它除了實(shí)現(xiàn) CRI 接口外，也要負(fù)責(zé)為容器配置網(wǎng)絡(luò)。一般推薦使用 CNI，因?yàn)檫@樣可以支持社區(qū)內(nèi)的眾多網(wǎng)絡(luò)插件，不過這不是必需的，網(wǎng)絡(luò)插件只需要滿足 Kubernetes 網(wǎng)絡(luò)的基本假設(shè)即可，即 IP-per-Pod、所有 Pod 和 Node 都可以直接通過 IP 相互訪問。

容器運(yùn)行時(shí)接口（CRI）

容器運(yùn)行時(shí)接口（CRI）是一個(gè)用來擴(kuò)展容器運(yùn)行時(shí)的接口，它基于 gPRC，用戶不需要關(guān)心內(nèi)部通信邏輯，而只需要實(shí)現(xiàn)定義的接口就可以，包括 RuntimeService 和 ImageService。

• RuntimeService負(fù)責(zé)管理Pod和容器的生命周期
• 而ImageService負(fù)責(zé)鏡像的生命周期管理

除了 gRPC API，CRI 還包括用于實(shí)現(xiàn) streaming server 的庫（用于 Exec、Attach、PortForward 等接口）和 CRI Tools。

image-20181014230459955

基于 CRI 接口的容器運(yùn)行時(shí)通常稱為 CRI shim， 這是一個(gè) gRPC Server，監(jiān)聽在本地的unix socket上；而kubelet作為gRPC的客戶端來調(diào)用CRI接口。另外，外部容器運(yùn)行時(shí)需要自己負(fù)責(zé)管理容器的網(wǎng)絡(luò)，推薦使用CNI，這樣跟Kubernetes的網(wǎng)絡(luò)模型保持一致。

CRI 的推出為容器社區(qū)帶來了新的繁榮，cri-o、frakti、cri-containerd 等一些列的容器運(yùn)行時(shí)為不同場景而生：

• cri-containerd——基于 containerd 的容器運(yùn)行時(shí)
• cri-o——基于 OCI 的容器運(yùn)行時(shí)
• frakti——基于虛擬化的容器運(yùn)行時(shí)

而基于這些容器運(yùn)行時(shí)，還可以輕易聯(lián)結(jié)新型的容器引擎，比如可以通過 clear container、gVisor 等新的容器引擎配合 cri-o 或 cri-containerd 等輕易接入 Kubernetes，將 Kubernetes 的應(yīng)用場景擴(kuò)展到了傳統(tǒng) IaaS 才能實(shí)現(xiàn)的強(qiáng)隔離和多租戶場景。

當(dāng)使用CRI運(yùn)行時(shí)，需要配置kubelet的--container-runtime參數(shù)為remote，并設(shè)置--container-runtime-endpoint為監(jiān)聽的unix socket位置（Windows上面為 tcp 端口）。

CRI 接口

CRI 接口包括 RuntimeService 和 ImageService 兩個(gè)服務(wù)，這兩個(gè)服務(wù)可以在一個(gè) gRPC server 里面實(shí)現(xiàn)，當(dāng)然也可以分開成兩個(gè)獨(dú)立服務(wù)。目前社區(qū)的很多運(yùn)行時(shí)都是將其在一個(gè) gRPC server 里面實(shí)現(xiàn)。

image-20181014230528339

管理鏡像的 ImageService 提供了 5 個(gè)接口，分別是查詢鏡像列表、拉取鏡像到本地、查詢鏡像狀態(tài)、刪除本地鏡像以及查詢鏡像占用空間等。這些都很容易映射到 docker API 或者 CLI 上面。

而 RuntimeService 則提供了更多的接口，按照功能可以劃分為四組：

• PodSandbox 的管理接口：PodSandbox 是對 Kubernete Pod 的抽象，用來給容器提供一個(gè)隔離的環(huán)境（比如掛載到相同的 cgroup 下面），并提供網(wǎng)絡(luò)等共享的命名空間。PodSandbox 通常對應(yīng)到一個(gè) Pause 容器或者一臺(tái)虛擬機(jī)。
• Container 的管理接口：在指定的 PodSandbox 中創(chuàng)建、啟動(dòng)、停止和刪除容器。
• Streaming API 接口：包括 Exec、Attach 和 PortForward 等三個(gè)和容器進(jìn)行數(shù)據(jù)交互的接口，這三個(gè)接口返回的是運(yùn)行時(shí) Streaming Server 的 URL，而不是直接跟容器交互。
• 狀態(tài)接口，包括查詢 API 版本和查詢運(yùn)行時(shí)狀態(tài)。

Streaming API

Streaming API 用于客戶端與容器進(jìn)行交互，包括Exec、PortForward 和 Attach 等三個(gè)接口。Kubelet 內(nèi)置的 docker 通過 nsenter、socat 等方法來支持這些特性，但它們不一定適用于其他的運(yùn)行時(shí)，也不支持 Linux 之外的其他平臺(tái)。因而，CRI 也顯式定義了這些 API，并且要求容器運(yùn)行時(shí)返回一個(gè) streaming server 的 URL 以便 Kubelet 重定向 API Server 發(fā)送過來的流式請求。

這是因?yàn)樗腥萜鞯牧魇秸埱蠖紩?huì)經(jīng)過 Kubelet，這有可能會(huì)給節(jié)點(diǎn)的網(wǎng)絡(luò)流量帶來瓶頸，因而 CRI 要求容器運(yùn)行時(shí)啟動(dòng)一個(gè)對應(yīng)請求的單獨(dú)的流服務(wù)器，將地址返回給Kubelet。Kubelet然后將這個(gè)信息再返回給Kubernetes API Server，它會(huì)打開直接與運(yùn)行時(shí)提供的服務(wù)器相連的流連接，并通過它跟客戶端連通。

image-20181014230541934

這樣一個(gè)完整的 Exec 流程就如上圖所示，分為多個(gè)階段：

• 客戶端 kubectl exec -i -t ...
• kube-apiserver 向 Kubelet 發(fā)送流式請求 /exec/
• Kubelet 通過 CRI 接口向 CRI Shim 請求 Exec 的 URL
• CRI Shim 向 Kubelet 返回 Exec URL
• Kubelet 向 kube-apiserver 返回重定向的響應(yīng)
• kube-apiserver 重定向流式請求到 Exec URL，接著就是 CRI Shim 內(nèi)部的 Streaming Server 跟 kube-apiserver 進(jìn)行數(shù)據(jù)交互，完成 Exec 的請求和響應(yīng)

在 v1.10 及更早版本中，容器運(yùn)行時(shí)必需返回一個(gè) API Server 可直接訪問的 URL（通常跟 Kubelet 使用相同的監(jiān)聽地址）；而從 v1.11 開始，Kubelet 新增了--redirect-container-streaming選項(xiàng)（默認(rèn)為 false），支持不轉(zhuǎn)發(fā)而是代理 Streaming 請求，這樣運(yùn)行時(shí)可以返回一個(gè) localhost 的 URL（當(dāng)然也不再需要配置 TLS）。

容器運(yùn)行時(shí)實(shí)例

以下是幾個(gè)常見容器運(yùn)行時(shí)的例子，它們各有所長，并且也支持不同的容器引擎：

多租戶

在多租戶場景下，強(qiáng)隔離（特別是虛擬化級(jí)別的隔離）是一個(gè)最基本的需求。

以前使用 Kubernetes 時(shí)，由于只支持Docker 容器，而它只提供了內(nèi)核命名空間（namespace）的隔離，雖然也支持 SELinux、AppArmor 等基本的安全控制，但還是無法滿足多租戶的需求。所以曾經(jīng)社區(qū)有人提出節(jié)點(diǎn)獨(dú)占的方式實(shí)現(xiàn)租戶隔離，即每個(gè)容器或租戶獨(dú)占一臺(tái)虛擬機(jī)，資源的浪費(fèi)是很明顯的。

有了 CRI 之后，就可以接入 Kata Container、Clear Container 等基于虛擬化的容器引擎。這樣通過虛擬化實(shí)現(xiàn)了容器的強(qiáng)隔離，不同租戶的容器也可以運(yùn)行在相同的 Node 上，大大提高了資源的利用率。

當(dāng)然了，多租戶不僅需要容器自身的強(qiáng)隔離，還需要眾多其他的功能一起配合，比如

• 網(wǎng)絡(luò)隔離，比如可以使用 CNI 構(gòu)建新的網(wǎng)絡(luò)插件，把不同租戶的 Pod 接入到相互隔離的虛擬網(wǎng)絡(luò)中。
• 資源管理，比如基于 CRD 構(gòu)建租戶 API 和租戶控制器，管理租戶和租戶的資源。
• 認(rèn)證、授權(quán)、配額管理等等也都可以在 Kubernetes API 之上構(gòu)建。

CRI Tools

CRI Tools 是社區(qū) Node 組針對 CRI 接口開發(fā)的輔助工具，它包括兩個(gè)工具：crictl 和 critest。

crictl 是一個(gè)容器運(yùn)行時(shí)命令行接口，它對系統(tǒng)和應(yīng)用的排錯(cuò)來說是個(gè)很有用的工具。當(dāng)使用 Docker 運(yùn)行時(shí)，調(diào)試系統(tǒng)信息的時(shí)候我們可能使用 docker ps 和 docker inspect 等命令檢查應(yīng)用的進(jìn)程情況。但是對于其他基于 CRI 的容器運(yùn)行時(shí)來說，它們可能沒有自己的命令行工具；或者即便有，它們的操作界面也不一定與 Kubernetes 中的概念一致。更不用說，很有很多的命令對 Kubernetes 沒什么用，甚至?xí)p害系統(tǒng)（比如 docker rename）。因而，我們推薦使用 crictl 作為 Docker CLI 的繼任者，用于 Kubernetes 節(jié)點(diǎn)上 pod、容器以及鏡像的除錯(cuò)工具。

crictl 提供了類似 Docker CLI 的使用體驗(yàn)， 并且支持所有 CRI 兼容的容器運(yùn)行時(shí)。并且，crictl 提供了一個(gè)對 Kubernetes 來說更加友好的容器視角：它就是為 Kubernetes 而設(shè)計(jì)的，有不同的命令分別與Pod 和容器進(jìn)行交互。例如 crictl pods 會(huì)列出 Pod 信息，而 crictl ps 只會(huì)列出應(yīng)用容器的信息。

而 critest 則是一個(gè)容器運(yùn)行時(shí)的驗(yàn)證測試工具，用于驗(yàn)證容器運(yùn)行時(shí)是否符合 Kubelet CRI 的要求。除了驗(yàn)證測試，critest 還提供了 CRI 接口的性能測試，比如 critest -benchmark。

推薦將 critest 集成到容器運(yùn)行時(shí)開發(fā)的 Devops 流程中，保證每個(gè)變更都不會(huì)破壞 CRI 的基本功能。另外，還可以選擇將 critest 的測試結(jié)果與 Kubernetes Node E2E 的結(jié)果提交到 Sig-node 的 TestGrid，向社區(qū)和用戶展示。

未來展望

最后一部分是容器運(yùn)行時(shí)的未來展望，這里討論兩個(gè)點(diǎn)，即多容器運(yùn)行時(shí) RuntimeClass 以及無服務(wù)器容器服務(wù)。

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

多容器運(yùn)行時(shí)用于不同的目的，比如使用虛擬化容器引擎式運(yùn)行不可信應(yīng)用和多租戶應(yīng)用，而使用 Docker 運(yùn)行系統(tǒng)組件或者無法虛擬化的容器（比如需要 HostNetwork 的容器）。比如典型的用例為：

• Kata Containers/gVisor + runc
• Windows Process isolation + Hyper-V isolation containers

以前，多容器運(yùn)行時(shí)通常以注解（Annotation）的形式支持，比如 cri-o、frakti 等都是這么支持了多容器運(yùn)行時(shí)。但這一點(diǎn)也不優(yōu)雅，并且也無法實(shí)現(xiàn)基于容器運(yùn)行時(shí)來調(diào)度容器。因而，Kubernetes 在 v1.12 中將開始增加 RuntimeClass 這個(gè)新的 API 對象，用來支持多容器運(yùn)行時(shí)。

RuntimeClass 表示一個(gè)運(yùn)行時(shí)，在使用前需要開啟特性開關(guān) RuntimeClass，并創(chuàng)建 RuntimeClass CRD：

kubectl apply -f https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml

然后就可以定義 RuntimeClass 對象

apiVersion: node.k8s.io/v1alpha1  # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
  name: myclass  # The name the RuntimeClass will be referenced by
  # RuntimeClass is a non-namespaced resource
spec:
  runtimeHandler: myconfiguration  # The name of the corresponding CRI configuration

接著，就可以在 Pod 中定義使用哪個(gè) RuntimeClass：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

在未來版本中，RuntimeClass還會(huì)支持基于 Node 上實(shí)際運(yùn)行的容器運(yùn)行時(shí)來調(diào)度 Pod。

無服務(wù)器容器服務(wù)

無服務(wù)器（Serverless）現(xiàn)在是一個(gè)很熱門的方向，各個(gè)云平臺(tái)也提供很多種類的無服務(wù)器計(jì)算服務(wù)，比如 Azure Container Instance、AWS Farget 等。它們的好處是用戶不需要去管理容器底層的基礎(chǔ)設(shè)施，而只需要管理容器即可，并且容器通常按實(shí)際的運(yùn)行時(shí)間收費(fèi)。這樣，對用戶來說，不僅省去了管理基礎(chǔ)設(shè)施的繁瑣步驟，還更節(jié)省成本。

那么 CRI 在這里有什么應(yīng)用場景呢？假如你是一個(gè)云平臺(tái)的管理者，想要構(gòu)建一個(gè)無服務(wù)器容器服務(wù)，那么使用 CRI 配合多容器運(yùn)行時(shí)就是一個(gè)很好的思路。這樣的話，

• Kubernetes 可以用來給整個(gè)平臺(tái)提供調(diào)度和編排
• 基于 Kubernetes API 可以搭建租戶管理功能
• 基于 CRI 可以實(shí)現(xiàn)多租戶容器運(yùn)行的強(qiáng)隔離
• 基于 CNI 可以實(shí)現(xiàn)多租戶的網(wǎng)絡(luò)強(qiáng)隔離

那么，對云平臺(tái)的用戶呢？這些無服務(wù)器容器服務(wù)提供的功能通常都比較簡單，并不具備編排的功能。但可以借助 Virtual Kubelet 項(xiàng)目，使用 Kubernetes 為這些平臺(tái)的容器提供編排功能。

Virtual Kubelet 是針對 Serverless 容器平臺(tái)設(shè)計(jì)的虛擬 Kubernetes 節(jié)點(diǎn)，它模擬了 Kubelet 的功能，并將 Serverless 容器平臺(tái)抽象為一個(gè)虛擬的無限資源的 Node。這樣就可以通過 Kubernetes API 來管理其上的容器。

image-20181014230850615

目前 Virtual Kubelet 已經(jīng)支持了眾多的云平臺(tái)，包括

• Azure Container Instance
• AWS Farget
• Service Fabric
• Hyper.sh
• IoT Edge

以上，就是“Kubernetes 容器運(yùn)行時(shí)演進(jìn)”的所有內(nèi)容。

總結(jié)

k8s使用內(nèi)置的CRI容器運(yùn)行時(shí)Dockershim,支持的容器引擎是docker,所以我們之前沒有配置CRI，也是可以使用容器運(yùn)行時(shí)的。
在官方文檔中https://kubernetes.io/zh/docs/setup/production-environment/container-runtimes/，介紹了配置containerd為容器運(yùn)行時(shí)的操作步驟，containerd不需要docker,容器引擎為OCI（runc、kata、gVisor…）。

轉(zhuǎn)載
Kubernetes 容器運(yùn)行時(shí)演進(jìn)