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

Kubernetes 容器運行時演進

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

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

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

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

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

Kubernetes 簡介

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

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

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

• etcd 保存了整個集群的狀態(tài)虑稼。
• kube-apiserver 提供了資源操作的唯一入口琳钉，并提供認證、授權(quán)蛛倦、訪問控制歌懒、API 注冊和發(fā)現(xiàn)等機制。并且無論是集群內(nèi)部還是外部的組件溯壶，都必須通過API Server來訪問數(shù)據(jù)及皂。
• kube-controller-manager 負責維護集群的狀態(tài)，包括很多資源的控制器茸塞，是保證 Kubernetes 聲明式 API 工作的大腦躲庄，比如故障檢測查剖、自動擴展钾虐、滾動更新等。
• kube-scheduler 負責資源的調(diào)度笋庄，按照預定的調(diào)度策略將 Pod 調(diào)度到相應的 Node 上效扫；

而 Node 則是負責運行具體的容器倔监，并為容器提供存儲、網(wǎng)絡等必要的功能：

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

image-20181014230247199

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

Kubelet 架構(gòu)

Kubelet 負責維持容器的生命周期近哟，同時也配合 kube-controller-manager 管理容器的存儲卷，并配合 CNI 管理容器的網(wǎng)絡鲫寄。接下來吉执，我們再來仔細看看 Kubelet 的架構(gòu)。

image

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

• Kubelet Server 對外提供 API戳玫，供 kube-apiserver、metrics-server 等服務調(diào)用未斑。比如 kubectl exec 時需要通過 Kubelet API /exec/{token} 與容器進行交互量九。
• Container Manager 管理容器的各種資源，比如 cgroups颂碧、QoS荠列、cpuset、device 等载城。
• Volume Manager 管理容器的存儲卷肌似，比如格式化資盤、掛載到 Node 本地诉瓦、最后再將掛載路徑傳給容器川队。
• Eviction 負責容器的驅(qū)逐，比如在資源不足時驅(qū)逐優(yōu)先級低的容器睬澡，保證高優(yōu)先級容器的運行固额。
• cAdvisor 負責為容器提供 metrics
• Metrics 和 stats 提供容器和節(jié)點的度量數(shù)據(jù)，比如 metrics-server 通過 /stats/summary 提取的度量數(shù)據(jù)是 HPA 自動擴展的依據(jù)煞聪。
• 再向下呢就是 Generic Runtime Manager斗躏，這是容器運行時的管理者，負責于 CRI 交互昔脯，完成容器和鏡像的管理
• 在 CRI 之下啄糙，包括兩種容器運行時的實現(xiàn)
  • 一個是內(nèi)置的 dockershim笛臣，實現(xiàn)了 docker 容器引擎的支持以及 CNI 網(wǎng)絡插件（包括 kubenet）的支持
  • 另一個就是外部的容器運行時，用來支持 runc隧饼、containerd沈堡、gvisor 等外部容器運行時

Kubelet 通過 CRI 接口跟外部容器運行時交互，它包括

• CRI Server燕雁，這是 CRI gRPC server诞丽，監(jiān)聽在 unix socket 上面
• Streaming Server，提供 streaming API拐格，包括 Exec率拒、Attach、Port Forward
• 容器和鏡像的管理禁荒，比如拉取鏡像猬膨、創(chuàng)建和啟動容器等
• CNI 網(wǎng)絡插件的支持，用于給容器配置網(wǎng)絡
• 最后是容器引擎的管理呛伴，比如支持 runc 勃痴、containerd 或者支持多個容器引擎

這樣，Kubernetes 中的容器運行時按照不同的功能就可以分為三個部分：

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

這樣的話，我們就可以基于這三個不同部分來看一看容器運行的演進過程奕锌。

容器運行時演進過程

image-20181014230405547

容器運行時的演進可以分為三個階段：

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

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

第三階段，從 v1.11 開始摔敛，Kubelet 內(nèi)置的 rkt 代碼刪除廷蓉，CNI 的實現(xiàn)遷移到 dockershim 之內(nèi)。這樣马昙，除了 docker 之外桃犬，其他的容器運行時都通過 CRI 接入。外部的容器運行時一般稱為 CRI Shim行楞，它除了實現(xiàn) CRI 接口外攒暇，也要負責為容器配置網(wǎng)絡。一般推薦使用 CNI子房，因為這樣可以支持社區(qū)內(nèi)的眾多網(wǎng)絡插件形用，不過這不是必需的，網(wǎng)絡插件只需要滿足 Kubernetes 網(wǎng)絡的基本假設即可证杭，即 IP-per-Pod田度、所有 Pod 和 Node 都可以直接通過 IP 相互訪問。

容器運行時接口（CRI）

容器運行時接口（CRI）是一個用來擴展容器運行時的接口解愤，它基于 gPRC每币，用戶不需要關(guān)心內(nèi)部通信邏輯，而只需要實現(xiàn)定義的接口就可以琢歇，包括 RuntimeService 和 ImageService兰怠。

• RuntimeService負責管理Pod和容器的生命周期
• 而ImageService負責鏡像的生命周期管理

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

image-20181014230459955

基于 CRI 接口的容器運行時通常稱為 CRI shim魄宏， 這是一個 gRPC Server秸侣，監(jiān)聽在本地的unix socket上；而kubelet作為gRPC的客戶端來調(diào)用CRI接口。另外味榛，外部容器運行時需要自己負責管理容器的網(wǎng)絡椭坚，推薦使用CNI，這樣跟Kubernetes的網(wǎng)絡模型保持一致搏色。

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

• cri-containerd——基于 containerd 的容器運行時
• cri-o——基于 OCI 的容器運行時
• frakti——基于虛擬化的容器運行時

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

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

CRI 接口

CRI 接口包括 RuntimeService 和 ImageService 兩個服務赚窃，這兩個服務可以在一個 gRPC server 里面實現(xiàn)当娱，當然也可以分開成兩個獨立服務。目前社區(qū)的很多運行時都是將其在一個 gRPC server 里面實現(xiàn)考榨。

image-20181014230528339

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

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

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

Streaming API

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

這是因為所有容器的流式請求都會經(jīng)過 Kubelet萍恕，這有可能會給節(jié)點的網(wǎng)絡流量帶來瓶頸，因而 CRI 要求容器運行時啟動一個對應請求的單獨的流服務器车要，將地址返回給Kubelet允粤。Kubelet然后將這個信息再返回給Kubernetes API Server，它會打開直接與運行時提供的服務器相連的流連接翼岁，并通過它跟客戶端連通类垫。

image-20181014230541934

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

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

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

容器運行時實例

以下是幾個常見容器運行時的例子，它們各有所長诺擅，并且也支持不同的容器引擎：

多租戶

在多租戶場景下，強隔離（特別是虛擬化級別的隔離）是一個最基本的需求二打。

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

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

當然了黎烈，多租戶不僅需要容器自身的強隔離习柠，還需要眾多其他的功能一起配合，比如

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

CRI Tools

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

crictl 是一個容器運行時命令行接口，它對系統(tǒng)和應用的排錯來說是個很有用的工具更米。當使用 Docker 運行時欺栗，調(diào)試系統(tǒng)信息的時候我們可能使用 docker ps 和 docker inspect 等命令檢查應用的進程情況。但是對于其他基于 CRI 的容器運行時來說征峦，它們可能沒有自己的命令行工具迟几；或者即便有，它們的操作界面也不一定與 Kubernetes 中的概念一致栏笆。更不用說类腮，很有很多的命令對 Kubernetes 沒什么用，甚至會損害系統(tǒng)（比如 docker rename）蛉加。因而蚜枢，我們推薦使用 crictl 作為 Docker CLI 的繼任者缸逃，用于 Kubernetes 節(jié)點上 pod、容器以及鏡像的除錯工具厂抽。

crictl 提供了類似 Docker CLI 的使用體驗需频， 并且支持所有 CRI 兼容的容器運行時。并且筷凤，crictl 提供了一個對 Kubernetes 來說更加友好的容器視角：它就是為 Kubernetes 而設計的昭殉，有不同的命令分別與Pod 和容器進行交互。例如 crictl pods 會列出 Pod 信息藐守，而 crictl ps 只會列出應用容器的信息挪丢。

而 critest 則是一個容器運行時的驗證測試工具，用于驗證容器運行時是否符合 Kubelet CRI 的要求卢厂。除了驗證測試乾蓬，critest 還提供了 CRI 接口的性能測試，比如 critest -benchmark足淆。

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

未來展望

最后一部分是容器運行時的未來展望丹鸿，這里討論兩個點，即多容器運行時 RuntimeClass 以及無服務器容器服務棚品。

多容器運行時

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

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

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

RuntimeClass 表示一個運行時酿傍，在使用前需要開啟特性開關(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 中定義使用哪個 RuntimeClass：

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

在未來版本中赤炒，RuntimeClass還會支持基于 Node 上實際運行的容器運行時來調(diào)度 Pod氯析。

無服務器容器服務

無服務器（Serverless）現(xiàn)在是一個很熱門的方向，各個云平臺也提供很多種類的無服務器計算服務莺褒，比如 Azure Container Instance魄鸦、AWS Farget 等。它們的好處是用戶不需要去管理容器底層的基礎設施癣朗，而只需要管理容器即可拾因，并且容器通常按實際的運行時間收費。這樣旷余，對用戶來說绢记，不僅省去了管理基礎設施的繁瑣步驟，還更節(jié)省成本正卧。

那么 CRI 在這里有什么應用場景呢蠢熄？假如你是一個云平臺的管理者，想要構(gòu)建一個無服務器容器服務炉旷，那么使用 CRI 配合多容器運行時就是一個很好的思路签孔。這樣的話，

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

那么窘行，對云平臺的用戶呢饥追？這些無服務器容器服務提供的功能通常都比較簡單，并不具備編排的功能罐盔。但可以借助 Virtual Kubelet 項目但绕，使用 Kubernetes 為這些平臺的容器提供編排功能。

Virtual Kubelet 是針對 Serverless 容器平臺設計的虛擬 Kubernetes 節(jié)點惶看，它模擬了 Kubelet 的功能盹牧，并將 Serverless 容器平臺抽象為一個虛擬的無限資源的 Node膳灶。這樣就可以通過 Kubernetes API 來管理其上的容器。

image-20181014230850615

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

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

以上望艺，就是“Kubernetes 容器運行時演進”的所有內(nèi)容矾麻。

總結(jié)

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

轉(zhuǎn)載
Kubernetes 容器運行時演進