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)然也提供了簡(jiǎn)便易用的擴(kuò)展接口，也就是 CRI(Container Runtime Interface)。

[[270445]]

本文將介紹 CRI 的由來、演進(jìn)以及未來展望，主要內(nèi)容分為四個(gè)部分：Kubernetes架構(gòu)簡(jiǎn)介、容器運(yùn)行時(shí)接口的基本原理、容器運(yùn)行時(shí)的演進(jìn)以及未來的展望。

Kubernetes 簡(jiǎn)介

我們知道，Kubernetes是一個(gè)開源的容器集群管理系統(tǒng)，它的發(fā)展非常迅速，已經(jīng)成為***和最活躍的容器編排系統(tǒng)。

從架構(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 注冊(cè)和發(fā)現(xiàn)等機(jī)制。
• kube-controller-manager 負(fù)責(zé)維護(hù)集群的狀態(tài)，包括很多資源的控制器，是保證 Kubernetes 聲明式 API 工作的大腦。
• 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)行。Kubelet 默認(rèn)的容器運(yùn)行時(shí)為 Docker;
• kube-proxy 負(fù)責(zé)為 Service 提供 cluster 內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡
• Network plugin 也就基于 CNI(Container Network Internface)負(fù)責(zé)為容器配置網(wǎng)絡(luò)。

除了這些核心的組件以外，Kubernetes 當(dāng)然還包含了很多豐富的功能，這些都是通過擴(kuò)展(Addon)的方式來部署的。比如 kube-dns 和 metrics-server 等，都是以容器的方式部署在集群里面，并提供 API 給其他組件調(diào)用。

提示：在 Kubernetes 中，通常你可以聽到兩種不同類型的擴(kuò)展 Kubernetes 功能的方式：1) ***種是擴(kuò)展(Addon)，比如 dashboard、EFK、Prometheus、各種 Operator 等，這些擴(kuò)展不需要 Kubernetes 提供標(biāo)準(zhǔn)的接口，但是都為 Kubernetes 增加了新的功能特性;2) 還有一種方式則是插件(Plugin)，比如 CNI、CRI、CSI、Device Plugin 等，這些都是 Kubernetes 各個(gè)核心組件提供了標(biāo)準(zhǔn)的內(nèi)置接口，而外部插件則是實(shí)現(xiàn)這些接口，從而將 Kubernetes 擴(kuò)展到更多的用例場(chǎng)景中。

Kubelet 架構(gòu)

剛才提到，Kubelet 負(fù)責(zé)維持容器的生命周期。除此之外，它也配合 kube-controller-manager 管理容器的存儲(chǔ)卷，并配合 CNI 管理容器的網(wǎng)絡(luò)。下面就是 Kubelet 的簡(jiǎn)單架構(gòu)示意圖：

你可以發(fā)現(xiàn)，Kubelet 也是有很多組件構(gòu)成，包括

• Kubelet Server 對(duì)外提供 API，供 kube-apiserver、metrics-server 等服務(wù)調(diào)用。比如 kubectl exec 需要通過 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 數(shù)據(jù)源。
• 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í)交互，而上圖右側(cè)就是 CRI 容器運(yùn)行時(shí)的架構(gòu)。它通常包括以下幾個(gè)組件：

• CRI Server，這是 CRI gRPC server，監(jiān)聽在 unix socket 上面。在討論容器運(yùn)行時(shí)的時(shí)候，這個(gè) Server 也通常成為 CRI shim(夾在容器引擎和Kubelet之間的一層)。
• Streaming Server，提供 streaming API，用在 Exec、Attach、Port Forward 等流式接口上。
• 容器和鏡像的管理，比如拉取鏡像、創(chuàng)建和啟動(dòng)容器等。
• CNI 網(wǎng)絡(luò)插件的支持，用于給容器配置網(wǎng)絡(luò)。
• ***是容器引擎(Container Engine)的管理，比如支持 runc 、containerd 或者支持多個(gè)容器引擎。

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

• ***個(gè)是 Kubelet 中容器運(yùn)行時(shí)的管理模塊 Generic Runtime Manager，它通過 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 等)。

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

容器運(yùn)行時(shí)接口(CRI)，顧名思義，用來在 Kubernetes 擴(kuò)展容器運(yùn)行時(shí)，從而用戶可以選擇自己喜歡的容器引擎。

CRI 是基于 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。這兩個(gè)稍后再作詳細(xì)介紹。

基于 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í)為不同場(chǎng)景而生：

• 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)用場(chǎng)景擴(kuò)展到了傳統(tǒng) IaaS 才能實(shí)現(xiàn)的強(qiáng)隔離和多租戶場(chǎng)景。

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

CRI 接口

那么，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)。

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

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

• PodSandbox 的管理接口：PodSandbox 是對(duì) Kubernete Pod 的抽象，用來給容器提供一個(gè)隔離的環(huán)境(比如掛載到相同的 cgroup 下面)，并提供網(wǎng)絡(luò)等共享的命名空間。PodSandbox 通常對(duì)應(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 用于客戶端與容器需要交互的場(chǎng)景，所以采用的是流式接口，包括 Exec、PortForward 和 Attach 等。Kubelet 內(nèi)置的 docker 通過 nsenter、socat 等方法來支持這些特性，但它們不一定適用于其他的運(yùn)行時(shí)。因而，CRI 也顯式定義了這些 API，并且要求容器運(yùn)行時(shí)返回一個(gè) streaming server 的 URL 以便 Kubelet 重定向 API Server 發(fā)送過來的流式請(qǐng)求。

這樣一個(gè)完整的 Exec 流程就是

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

在 v1.10 及更早版本中，容器運(yùn)行時(shí)必需返回一個(gè) API Server 可直接訪問的 URL(通常跟 Kubelet 使用相同的監(jiān)聽地址);而從 v1.11 開始，Kubelet 新增了 --redirect-container-streaming(默認(rèn)為 false)，默認(rèn)不再轉(zhuǎn)發(fā)而是代理 Streaming 請(qǐng)求，這樣運(yùn)行時(shí)可以返回一個(gè) localhost 的 URL。通過 Kubelet 代理的好處是由 Kubelet 處理與 API server 通信之間的請(qǐng)求認(rèn)證。

實(shí)際上，各個(gè)運(yùn)行時(shí) streaming server 的處理框架都是類似的，因而 Kubelet 也提供來一個(gè) steaming server 庫，方便容器運(yùn)行時(shí)的開發(fā)者引用。

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

了解了容器運(yùn)行時(shí)接口的基本原理之后，接下來，我們?cè)賮砜匆幌氯萜鬟\(yùn)行時(shí)的演進(jìn)過程。

容器運(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í)除了實(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 相互訪問。

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

CRI 的推出為容器社區(qū)帶來了新的繁榮，適用于各種不同場(chǎng)景的運(yùn)行時(shí)也應(yīng)運(yùn)而生。比如：

這里也注意區(qū)分 CRI 容器運(yùn)行時(shí)與容器引擎的區(qū)別：

• CRI 容器運(yùn)行時(shí)是指實(shí)現(xiàn)了 Kubelet CRI 接口的運(yùn)行時(shí)，這樣就可以無縫集成到 Kubernetes 之中。
• 容器引擎只是負(fù)責(zé)管理容器鏡像和容器運(yùn)行的一個(gè)服務(wù)，它也有一個(gè)標(biāo)準(zhǔn)是 OCI(Open Container Initiative)。

比如 CNCF 的 Container Runtime Landscape 中包括了一些列的“Container Runtime”，這其中有一些是實(shí)現(xiàn)了 CRI 的，比如 cri-o;而更多的則只是一個(gè)容器引擎，需要通過 cri-o、cri-containerd 等才可以應(yīng)用到 Kubernetes 之中。

CRI Tools

CRI Tools 對(duì) Kubernetes 容器運(yùn)行時(shí)和容器應(yīng)用的排錯(cuò)來說是一個(gè)非常有用的工具。它是一個(gè) SIG Node 所屬的子項(xiàng)目，可以應(yīng)用到所有實(shí)現(xiàn)了 CRI 接口的容器運(yùn)行時(shí)中。CRI Tools 包括兩個(gè)組件，crictl 用于排錯(cuò)和調(diào)試，而 critest 用于容器運(yùn)行時(shí)實(shí)現(xiàn)進(jìn)行一致性驗(yàn)證。

crictl

先來看 crictl。crictl 提供了一個(gè)類似了 docker 命令的命令行工具。在排錯(cuò)或者調(diào)試容器應(yīng)用時(shí)，有時(shí)候系統(tǒng)管理員需要登錄到節(jié)點(diǎn)上去查看容器或鏡像的狀態(tài)，以便收集系統(tǒng)和容器應(yīng)用的信息。這時(shí)候，推薦使用 crictl 來完成這些工作，因?yàn)?crictl 為所有不同的容器引擎都提供了一個(gè)一致的使用體驗(yàn)。

從使用上來說，crictl 的使用非常類似于 docker 命令行工具，比如你可以使用 crictl pods 來查詢 PodSandbox 的列表、使用 crictl ps 來查詢?nèi)萜鞯牧斜?、使?crictl images 查詢鏡像列表。

需要注意的是，crictl 的設(shè)計(jì)目標(biāo)是排錯(cuò)，而并非 docker 或者 kubectl 等的替代品。比如，由于 CRI 并沒有定義鏡像構(gòu)建的接口，crictl 并不提供 docker build 這種構(gòu)建鏡像的功能。但由于 crictl 提供了一個(gè)面向 Kubernetes 的接口，相對(duì)于 docker 來說，crictl 可以提供一個(gè)對(duì)容器和 Pod 更清晰的視圖。

critest

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

推薦將 critest 集成到 CRI 容器運(yùn)行時(shí)的 Devops 流程中，保證每個(gè)變更都不會(huì)破壞 CRI 的基本功能。

另外，還可以選擇將 critest 與 Kubernetes Node E2E 的測(cè)試結(jié)果提交到 Sig-node 的 TestGrid，向社區(qū)和用戶展示。

未來展望

Docker 運(yùn)行時(shí)拆分

目前 Docker 是內(nèi)置在 Kubelet 中的一個(gè)運(yùn)行時(shí)，也是默認(rèn)的容器運(yùn)行時(shí)。這樣，實(shí)際上 Kubelet 就會(huì)依賴于 Docker，從而為 Kubelet 本身帶來一定的維護(hù)負(fù)擔(dān)。

比如，Kubelet 內(nèi)部有些功能可能只是適用于 Docker 運(yùn)行時(shí)。當(dāng) Docker 或者 Docker 依賴的其他組件(比如 containerd、runc)發(fā)現(xiàn)嚴(yán)重缺陷時(shí)，修復(fù)這些缺陷就需要重現(xiàn)編譯和發(fā)布 Kubelet。

此外，當(dāng)用戶想要在 Docker 運(yùn)行時(shí)中新增功能時(shí)，這些新增的功能可能并不容易引入到 Kubelet 中，特別是三個(gè)月的發(fā)布周期中，新的特性通常不會(huì)引入到現(xiàn)有的穩(wěn)定分支中。從 Docker 運(yùn)行時(shí)的角度來說，新特性的引入通常也會(huì)比較緩慢。

所以，拆分 Docker 容器引擎，將其獨(dú)立出去成為一個(gè) cri-docker 就可以解決上述的所有問題。

由于 Docker 作為默認(rèn)的容器引擎，在生產(chǎn)環(huán)境中已經(jīng)得到廣泛應(yīng)用，拆分和遷移會(huì)應(yīng)用絕大部分用戶，因?yàn)榫唧w的遷移方法還需要社區(qū)的詳細(xì)討論。

強(qiáng)隔離容器引擎

雖然 Kubernetes 提供了基本的多租戶功能，可以不同應(yīng)用放到不同 namespace 中進(jìn)行隔離，也可以使用 RBAC 控制不同用戶對(duì)各類資源的訪問，但由于 Docker 共享內(nèi)核的特性，在 Kubernetes 中運(yùn)行不可信應(yīng)用時(shí)還是有很大的安全隱患。為了消除這個(gè)問題，強(qiáng)隔離容器引擎應(yīng)運(yùn)而生。

最早的強(qiáng)隔離容器引擎就是 Kata containers 的前身 hyperd 和 clear container，它將 Kubernetes Pod 作為一個(gè)虛擬機(jī)來運(yùn)行，這樣就可以通過虛擬化的方式對(duì)容器應(yīng)用進(jìn)行強(qiáng)隔離。虛擬化是整個(gè)云計(jì)算中 IaaS 的基礎(chǔ)，它的安全性已經(jīng)得到了廣泛驗(yàn)證，因而其安全性也就得到了保證。這兩個(gè)項(xiàng)目目前已經(jīng)合并成為 Kata containers。

除了 Kata containers 之外，Google 和 AWS 也在推進(jìn)強(qiáng)隔離的容器引擎，也就是 gVisor 和 Firecraker。

跟 Kata containers 不同，gVisor 并不會(huì)去創(chuàng)建一個(gè)完整的 VM，而是實(shí)現(xiàn)了一個(gè)自己的沙箱(文檔成為用戶態(tài)內(nèi)核)，攔截和過濾容器的 syscall，從而達(dá)到安全隔離的目的。雖然 gVisor 相對(duì)于 VM 來說更輕量化，但攔截過濾也會(huì)帶來很高的成本，對(duì)最終容器應(yīng)用的性能會(huì)造成一定損失。

同樣的，F(xiàn)irecraker 基于 KVM 實(shí)現(xiàn)了一個(gè)輕量級(jí)的 VM，稱為 microVM。跟 Kata 不同的是，它沒有使用 QEMU，而是用 Rust 構(gòu)建了一套精簡(jiǎn)的設(shè)備模型，從而讓每個(gè) microVM 只占用大約 5MB 的內(nèi)存。

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

有了強(qiáng)隔離的容器引擎后，不可避免的就出現(xiàn)了一些新的問題。比如，很多 Kubernetes 自身的服務(wù)或者擴(kuò)展由于需要 HostNetwork 或特權(quán)模式，無法運(yùn)行在強(qiáng)隔離的環(huán)境中。所以，多容器運(yùn)行時(shí)也就應(yīng)運(yùn)而生了。

這樣，就可以使用 runc/docker 等運(yùn)行特權(quán)應(yīng)用，而使用強(qiáng)隔離容器引擎運(yùn)行普通應(yīng)用。比如，典型的組合為：

• runc + kata
• runc + gVisor
• Windows server containers + Hyper-V containers

以前，很多容器運(yùn)行時(shí)都是在 CRI Shim 中支持多個(gè)容器引擎，并通過 Annotations 的形式選擇。而借助于新的 RuntimeClass 資源，就可以直接通過 Pod Spec 來選擇不同的 runtime。

apiVersion: node.k8s.io/v1beta1 
kind: RuntimeClass 
metadata: 
 name: myclas 
# RuntimeClass is non-namespaced 
handler: myconfiguration 
--- 
apiVersion: v1  
kind: Pod  
metadata: 
 name: mypod  
spec: 
 runtimeClassName: myclass 
 # ... 

RuntimeClass 本身還處在比較早期的階段，未來還會(huì)繼續(xù)在調(diào)度等方面進(jìn)一步增強(qiáng)。