目錄

一、理論

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

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

?3.容器運(yùn)行時(shí)層級(jí)

4.容器運(yùn)行時(shí)比較

5.強(qiáng)隔離容器

二、問(wèn)題

1.K8S為何難以實(shí)現(xiàn)真正的多租戶

三、總結(jié)

---

一、理論

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

（1）概念

Container Runtime 是運(yùn)行于 k8s 集群每個(gè)節(jié)點(diǎn)中，負(fù)責(zé)容器的整個(gè)生命周期。Docker 就目前來(lái)說(shuō)是應(yīng)用最為廣泛的。隨著容器云的發(fā)展，涌現(xiàn)了很多容器運(yùn)行時(shí)。Google 為了將 kubelet 和特定的容器運(yùn)行時(shí)解耦（主要還是為了干掉 Docker），于是推出了 CRI（容器運(yùn)行時(shí)接口）。

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

CRI 是 k8s 定義的一組 gRPC 服務(wù)。kubelet 作為客戶端，基于 gRPC 框架，通過(guò) Socket 和容器運(yùn)行時(shí)通信。CRI 包括兩類服務(wù)：鏡像服務(wù)（Image Service）和運(yùn)行時(shí)服務(wù)（Runtime Service）。鏡像服務(wù)提供下載、檢查和刪除鏡像的遠(yuǎn)程程序調(diào)用。運(yùn)行時(shí)服務(wù)用于管理容器的生命周期，以及和容器交互的調(diào)用（exec / attach / port-forward）。

?3.容器運(yùn)行時(shí)層級(jí)

Container Runtime 分為高低兩個(gè)層級(jí)。

（1）??高層級(jí)運(yùn)行時(shí)
Dockershim、containerd 和 CRI-O 都是遵循 CRI 的容器運(yùn)行時(shí)，屬于高層級(jí)運(yùn)行時(shí)，主要是面向外部提供 gRPC 調(diào)用。

注意這里是 Dockershim，并不是 Docker，Docker 至今也沒(méi)有遵循 CRI。

OCI
OCI（OPen Container Initiative）定義了創(chuàng)建容器的格式和運(yùn)行時(shí)的開(kāi)源行業(yè)標(biāo)準(zhǔn)，包括鏡像規(guī)范和運(yùn)行時(shí)規(guī)范。

高層級(jí)運(yùn)行時(shí)會(huì)下載一個(gè) OCI 鏡像，并把它解壓成 OCI 運(yùn)行時(shí)文件系統(tǒng)包（filesystem bundle）。

（2）低層級(jí)運(yùn)行時(shí)
低層級(jí)運(yùn)行時(shí)定義如何為新容器設(shè)置 Linux namespaces 和 cgroups，以及 rootfs 等操作， runC 就是具體的參考實(shí)現(xiàn)。除了 runC 外，還有很多其他的運(yùn)行時(shí)遵循 OCI 標(biāo)準(zhǔn)，例如 kata 以及 gVisor。

4.容器運(yùn)行時(shí)比較

Docker 的多層封裝和調(diào)用，導(dǎo)致其在可維護(hù)性上略遜一籌。containerd 和 CRI-O 的方案比 Docker 簡(jiǎn)潔很多。

dockershim 遵循 CRI，并把請(qǐng)求轉(zhuǎn)為 dockerd 可處理的請(qǐng)求，其代碼集成在 kubelet 中，這也是 k8s 急于擺脫 Docker 的原因之一。

真正的啟動(dòng)容器是通過(guò) containerd-shim 去調(diào)用 runC 來(lái)啟動(dòng)容器的，runC 啟動(dòng)完成后會(huì)直接退出，containerd-shim 會(huì)成為容器進(jìn)程的父進(jìn)程，負(fù)責(zé)收集容器進(jìn)程的狀態(tài)，上報(bào)給 containerd，并在容器中 pid 為 1 的進(jìn)程退出后接管容器中的子進(jìn)程，確保不會(huì)出現(xiàn)僵尸進(jìn)程。同時(shí)也避免了宿主機(jī)上 containerd 進(jìn)程掛掉的話，所有容器進(jìn)程都退出。

（1） containerd 和 Docker 細(xì)節(jié)差異

?Docker 作為容器運(yùn)行時(shí)，k8s 其實(shí)根本沒(méi)有使用 docker 本身的存儲(chǔ)、網(wǎng)絡(luò)等功能，只是用了 Docker 的 Image 功能，來(lái)滿足 CRI 中的鏡像服務(wù)。

（2）containerd 和 CRI-O

CRI-O是由紅帽發(fā)起并開(kāi)源的一款容器運(yùn)行時(shí)，本身比較新，沒(méi)有太多的生產(chǎn)實(shí)踐。而且在社區(qū)的測(cè)試結(jié)果中，在操作容器方面的性能以及延時(shí)都沒(méi)有 containerd 優(yōu)秀。

5.強(qiáng)隔離容器

（1）常用強(qiáng)隔離容器

Kata, gVisor, firecracker

（2）安全容器與 Serverless

Serverless 要做到所有的用戶容器或函數(shù)按需使用計(jì)算資源, 那必須滿足兩點(diǎn):

多租戶強(qiáng)隔離: 用戶的容器或函數(shù)都是按需啟動(dòng)按秒計(jì)費(fèi), 我們可不能給每個(gè)用戶預(yù)先分配一坨隔離的資源,因此我們要保證整個(gè) Platform 是多租戶強(qiáng)隔離的;
極度輕量: Serverless 的第一個(gè)特點(diǎn)是運(yùn)行時(shí)沙箱會(huì)更頻繁地創(chuàng)建和銷毀, 第二個(gè)特點(diǎn)是切分的粒度會(huì)非常非常細(xì), 細(xì)中細(xì)就是 FaaS, 一個(gè)函數(shù)就要一個(gè)沙箱。 因此就要求兩點(diǎn): 1. 沙箱啟動(dòng)刪除必須飛快; 2. 沙箱占用的資源越少越好。

（3）Kata Containers

① 概念

Kata Containers作為OpenStack基金會(huì)的一個(gè)開(kāi)放源代碼項(xiàng)目，作為其最近擴(kuò)展的包含OpenStack核心項(xiàng)目的章程的一部分。這個(gè)項(xiàng)目肯定會(huì)促進(jìn)標(biāo)準(zhǔn)化和創(chuàng)新，從而推動(dòng)容器技術(shù)的快速發(fā)展。已經(jīng)有將近20家公司同意在Kata Containers上共同合作。

Kata容器也將在多個(gè)基礎(chǔ)架構(gòu)和容器編排和規(guī)范社區(qū)中集成和兼容：Kubernetes，Docker，Open Container Initiative（OCI），Container Runtime Interface（CRI），容器網(wǎng)絡(luò)接口（CNI），QEMU，KVM，HyperV和OpenStack。

② 特點(diǎn)?

容器的速度，虛擬機(jī)的安全。

Kata 的一張圖很好地解釋了基于虛擬機(jī)的容器與基于 namespaces 和 cgroups 的容器間的區(qū)別:

Kata Containers是一種輕量級(jí)虛擬機(jī)的新穎實(shí)現(xiàn)無(wú)縫集成在容器生態(tài)系統(tǒng)中。Kata Containers同容器一樣輕而快，并與容器結(jié)合管理層，同時(shí)也提供了虛擬機(jī)的安全優(yōu)勢(shì)。

Kata Containers是兩個(gè)現(xiàn)有的開(kāi)源項(xiàng)目合并：英特爾Clear Containers和Hyper runV。新項(xiàng)目匯集了最好的這兩種技術(shù)都具有重構(gòu)虛擬化，容器原生應(yīng)用程序的共同愿景，為了提供容器的速度，和虛擬機(jī)的安全。

Kata Containers從每個(gè)項(xiàng)目的優(yōu)勢(shì)中受益。Intel Clear Containers專注于性能（<100ms啟動(dòng)時(shí)間）和增強(qiáng)安全性，而hyper runV優(yōu)先于技術(shù)無(wú)關(guān)支持許多不同的CPU架構(gòu)和管理程序。通過(guò)合并這些項(xiàng)目，Clear Containers提供了卓越的最終用戶體驗(yàn)性能和兼容性，統(tǒng)一開(kāi)發(fā)者社區(qū)，并加速功能開(kāi)發(fā)以解決未來(lái)的使用案例。

行業(yè)轉(zhuǎn)向容器在安全方面提出了獨(dú)特的挑戰(zhàn)，用戶工作負(fù)載在多租戶不受信任的環(huán)境中。Kata Containers使用開(kāi)源虛擬機(jī)管理程序作為每個(gè)容器的隔離邊界（或一個(gè)容器中的容器的集合）;這種方法解決了與現(xiàn)有的裸機(jī)容器解決方案共同的內(nèi)核困境。

Kata Containers是非常適合按需，基于事件的部署，如無(wú)服務(wù)器功能，連續(xù)整合/持續(xù)交付，以及更長(zhǎng)時(shí)間運(yùn)行的Web服務(wù)器應(yīng)用。開(kāi)發(fā)者不再需要知道任何事情下面的基礎(chǔ)或執(zhí)行任何類型的容量規(guī)劃之前啟動(dòng)他們的容器工作量。Kata Containers交付增強(qiáng)安全性，可擴(kuò)展性和更高的資源利用率，同時(shí)導(dǎo)致整體簡(jiǎn)化的堆棧。

二、問(wèn)題

1.K8S為何難以實(shí)現(xiàn)真正的多租戶

（1）問(wèn)題

k8s 做不到多租戶狀態(tài), 其中最大的兩個(gè)原因是:

1.kube-apiserver 是整個(gè)集群中的單例, 并且沒(méi)有多租戶概念；2.默認(rèn)的 oci-runtime 是 runC, 而 runC 啟動(dòng)的容器是共享內(nèi)核的。

?(2) 原因

理想的多租戶狀態(tài):

理想來(lái)說(shuō), 平臺(tái)的各個(gè)租戶(tenant)之間應(yīng)該無(wú)法感受到彼此的存在, 表現(xiàn)得就像每個(gè)租戶獨(dú)占這整個(gè)平臺(tái)一樣. 具體來(lái)說(shuō), 我不能看到其它租戶的資源, 我的資源跑滿了不能影響其它租戶的資源使用, 我也無(wú)法從網(wǎng)絡(luò)或內(nèi)核上攻擊其它租戶。

（3）解決方法

對(duì)于第二個(gè)問(wèn)題, 一個(gè)典型的解決方案就是提供一個(gè)新的 OCI 實(shí)現(xiàn), 用 VM 來(lái)跑容器, 實(shí)現(xiàn)內(nèi)核上的硬隔離。?runV?和?Clear Containers?都是這個(gè)思路. 因?yàn)檫@兩個(gè)項(xiàng)目做得事情是很類似, 后來(lái)就合并成了一個(gè)項(xiàng)目?Kata Container。

三、總結(jié)

runtime容器運(yùn)行時(shí)：
?高層級(jí)運(yùn)行時(shí)（Dockershim、containerd 和 CRI-O ），主要是面向外部提供 gRPC 調(diào)用。
?低層級(jí)運(yùn)行時(shí)（runC、kata和gVisor ），定義如何為新容器設(shè)置 Linux namespaces 和 cgroups，以及 rootfs 等操作。