作者|張磊

Kubernetes 項(xiàng)目目前的重點(diǎn)發(fā)展方向，是為開發(fā)者和使用者暴露更多的接口和可擴(kuò)展機(jī)制，將更多的用戶需求下放到社區(qū)來完成。其中，發(fā)展最為成熟也最為重要的一個(gè)接口就是 CRI。2018 年，由 containerd 社區(qū)主導(dǎo)的 shimv2 API 的出現(xiàn)，在 CRI 的基礎(chǔ)上，為用戶集成自己的容器運(yùn)行時(shí)帶來了更加成熟和方便的實(shí)踐方法。

本次演講分享了關(guān)于 Kubernetes 接口化設(shè)計(jì)、CRI、容器運(yùn)行時(shí)、shimv2、RuntimeClass 等關(guān)鍵技術(shù)特性的設(shè)計(jì)與實(shí)現(xiàn)，并以 KataContainers 為例，為聽眾演示上述技術(shù)特性的使用方法。本文整理自張磊在?KubeCon + CloudNativeCon 2018?現(xiàn)場(chǎng)的演講速記。

今天，我給大家?guī)淼姆窒硎顷P(guān)于 Kubernetes CRI 和 containerd shimv2 的設(shè)計(jì)，這也是目前社區(qū)里比較重要的一個(gè)大方向。大家好，我是張磊，現(xiàn)在在阿里巴巴集團(tuán)工作。既然今天咱們會(huì)聊 Kubernetes 這個(gè)項(xiàng)目，那么首先我們來簡(jiǎn)單看一下?Kubernetes?這個(gè)項(xiàng)目的工作原理。

Kubernetes 的工作原理

其實(shí)大家都知道 Kubernetes?這個(gè)項(xiàng)目它最上面是一層 Control Panel ，它也被很多人稱之為 Master 節(jié)點(diǎn)。當(dāng)你把 workload 就是你的應(yīng)用提交給 Kubernetes 之后，首先為你做事情的是 API server，它會(huì)把你的 Application 存到 etcd 里，以 API 對(duì)象的方式存到 etcd 中去。

而 Kubernetes 中負(fù)責(zé)編排的是 Controller manager，一堆 controller 通過控制循環(huán)在 run。通過這個(gè)控制循環(huán)來做編排工作，幫你去創(chuàng)建出這些應(yīng)用所需要的 Pod，注意不是容器，是 Pod。

而一旦一個(gè) Pod 出現(xiàn)之后，Scheduler 會(huì) watch 新 Pod 的變化。如果他發(fā)現(xiàn)有一個(gè)新的 Pod 出現(xiàn)，Scheduler 會(huì)幫你去把所有調(diào)度算法都 run 一遍，把 run 到的結(jié)果：就是一個(gè) Node 的名字，寫在我這個(gè) Pod 對(duì)象 NodeName 字段上面，就是一個(gè)所謂的 bind 的操作。然后把 bind 的結(jié)果寫回到 etcd 里去，這就是所謂的 Scheduler 工作過程。所以 Control Panel 它忙活這么一圈下來，最后得到的結(jié)果是什么呢？你的一個(gè) Pod 跟一個(gè) Node 綁定（bind）在了一起，就是所謂 Schedule 了。

而 Kubelet 呢？它是運(yùn)行在所有節(jié)點(diǎn)上。Kubelet 會(huì) watch 所有 Pod 對(duì)象的變化，當(dāng)它發(fā)現(xiàn)一個(gè) Pod 與一個(gè) ?Node 綁定在一起的時(shí)，并且它又發(fā)現(xiàn)這個(gè)被綁定的 Node 是它自己，那么 Kubelet?就會(huì)幫你去接管接下來的所有事情。

如果你看一下?Kubelet?，看看它在做什么呢？很簡(jiǎn)單，其實(shí)當(dāng) Kubelet?拿到這個(gè)信息之后，他是去 call 你運(yùn)行在每個(gè)機(jī)器上的 Containerd 進(jìn)程，去 run 這個(gè) Pod 里的每一個(gè)容器。

?

這時(shí)候，Containerd 幫你去 call runC 所以最后其實(shí)是 runC 幫你去 set up 起來這些 namespace、Cgroup 這些東西，是它去幫你 ?chroot ，“搭”出來所謂的一個(gè)應(yīng)用和需要的容器。這就是整個(gè) Kubernetes 工作的一個(gè)簡(jiǎn)單原理。

Linux Container

所以這個(gè)時(shí)候你可能會(huì)提出一個(gè)問題就是什么是容器？其實(shí)容器非常簡(jiǎn)單，我們平常所說這個(gè)容器就是 Linux 容器，你可以把 Linux 容器分為兩部分：第一個(gè)是 Container Runtime，第二個(gè)是 Container Image。

所謂的 Runtime 部分就是你所運(yùn)行進(jìn)程的動(dòng)態(tài)視圖和資源邊界，所以它是由? Namespace 和 Cgroup 為你構(gòu)建出來的。而對(duì)于 Image（鏡像），你可以把它理解為是你想要運(yùn)行的程序的靜態(tài)視圖，所以它其實(shí)是你的程序+數(shù)據(jù)+所有的依賴+所有的目錄文件組成一個(gè)壓縮包而已。

?

而這些壓縮包被以 union mount 的方式 mount 在一起的時(shí)候，我們稱之為 rootfs 。rootfs 就是你的整個(gè) process 的靜態(tài)視圖，他們看到這個(gè)世界就這樣子，所以這是 Linux Container。

KataContainer

可今天我們還要聊另外一種 Container，它與前面?Linux Container?截然不同。他的 Container Runtime 是用 hypervisor 實(shí)現(xiàn)的，是用 hardware virtualization?實(shí)現(xiàn)的，像個(gè)虛擬機(jī)一樣。所以每一個(gè)像這樣的 KataContainer 的 Pod，都是一個(gè)輕量級(jí)虛擬機(jī)，它是有完整的 Linux 內(nèi)核。所以我們經(jīng)常說?KataContainer 與?VM 一樣能提供強(qiáng)隔離性，但由于它的優(yōu)化和性能設(shè)計(jì)，它擁有與容器項(xiàng)媲美的敏捷性。這個(gè)一點(diǎn)稍后會(huì)強(qiáng)調(diào)，而對(duì)于鏡像部分， KataContainer 與 Docker 這些項(xiàng)目沒有任何不同，它使用的是標(biāo)準(zhǔn) Linux Continer 容器，支持標(biāo)準(zhǔn)的 OCR Image 所以這一部分是完全一樣的。

容器安全

可是你可能會(huì)問為什么我們會(huì)有 KataContainer 這種項(xiàng)目? 其實(shí)很簡(jiǎn)單，因?yàn)槲覀冴P(guān)心安全這個(gè)事，比如很多金融的場(chǎng)景、加密的場(chǎng)景，甚至現(xiàn)在區(qū)塊鏈很多場(chǎng)景下，都需要一個(gè)安全的 Container Runtime，所以這是我們強(qiáng)調(diào) KataContainer 的一個(gè)原因。

如果你現(xiàn)在正在使用 Docker， 我問一個(gè)問題就是你怎樣才能安全地使用 Docker？你可能會(huì)有很多套路去做。比如說你會(huì) drop 掉一些 Linux capibility，你可以去指定 Runtime 可以做什么，不能做什么。第二個(gè)你可以去 read-only mount points 。第三，你可以使用 SELinux 或者 AppArmor 這些工具把容器給保護(hù)起來。還有一種方式是可以直接拒絕一些 syscalls，可以用到 SECCOMP。

?

但是我需要強(qiáng)調(diào)的是所有這些操作都會(huì)在你的 Container 和 Host 之間引入新的 layer，因?yàn)樗プ鲞^濾，它要去攔截你的 syscalls，所以這個(gè)部分你搭的層越多，你容器性能越差，它一定是有額外的負(fù)面性能損耗的。

更重要的是,做這些事情之前你要想清楚到底應(yīng)該干什么，到底應(yīng)該 drop 掉哪些 syscalls，這個(gè)是需要具體問題具體分析的，那么這時(shí)候我應(yīng)該怎么去跟我的用戶去講如何做這件事情？

所以，這些事情說起來很簡(jiǎn)單，但實(shí)際執(zhí)行起來很少有人知道到底該怎么去做。所以在 99.99% 的情況下，大多數(shù)人都是把容器 run 到虛擬機(jī)里去的，尤其在公有云場(chǎng)景下。

而對(duì)于 KataContainer 這種項(xiàng)目來說，它由于使用了與虛擬機(jī)一樣的 hardware virualization，它是有獨(dú)立內(nèi)核的，所以這個(gè)時(shí)候它提供的 isolation 是完全可信任的，就與你信任 VM 是一樣的。

?

更重要的是，由于現(xiàn)在每一個(gè) Pod 里是有一個(gè) Independent Kernel，跟個(gè)小虛擬機(jī)一樣，所以這時(shí)候就允許你容器運(yùn)行的 Kernel 版本跟 Host machine 適應(yīng)是完全不一樣。這是完全 OK 的，就與你在在虛擬機(jī)中做這件事一樣，所以這就是為什么我會(huì)強(qiáng)調(diào) KataContainers 的一個(gè)原因，因?yàn)樗峁┝税踩投嘧鈶舻哪芰Α?/p>

Kubernetes + 安全容器

所以也就很自然會(huì)與有一個(gè)需求，就是我們?cè)趺慈グ?KataContainer run 在 Kubernetes 里??

那么這個(gè)時(shí)候我們還是先來看 Kubelet 在做什么事情，所以 Kubelet 要想辦法像 call Containerd 一樣去 call KataContainer，然后由 KataContainer 負(fù)責(zé)幫忙把 hypervisor 這些東西 set up 起來，幫我把這個(gè)小VM 運(yùn)行起來。所以這個(gè)時(shí)候就要需要想怎么讓 Kubernetes 能合理的操作 KataContainers。

Container Runtime Interface（CRI）

對(duì)于這個(gè)訴求，就關(guān)系到了我們之前一直在社區(qū)推進(jìn)的 Container Runtime Interface ，我們叫它 CRI。CRI 的作用其實(shí)只有一個(gè)：就是它描述了，對(duì)于 Kubernetes 來說，一個(gè) Container 應(yīng)該有哪些操作，每個(gè)操作有哪些參數(shù)，這就是 CRI 的一個(gè)設(shè)計(jì)原理。但需要注意的是，CRI 是一個(gè)以容器為核心的 API，它里面沒有 Pod 的這個(gè)概念。這個(gè)要記住。

為什么這么說呢？我們?yōu)槭裁匆@么設(shè)計(jì)呢？很簡(jiǎn)單，我們不希望像 Docker 這樣的項(xiàng)目，必須得懂什么是 Pod，暴露出 Pod 的 API，這是不合理的訴求。Pod 永遠(yuǎn)都是一個(gè) Kubernetes 的編排概念，這跟容器沒有關(guān)系，所以這就是為什么我們要把這個(gè) API 做成 Containerd -centric。

另外一個(gè)原因出于 maintain 的考慮，因?yàn)槿绻F(xiàn)在， CRI 里有 Pod 這個(gè)概念，那么接下來任何一個(gè) Pod feature 的變更都有可能會(huì)引起 CRI 的變動(dòng)，對(duì)于一個(gè)接口來說，這樣的維護(hù)代價(jià)是比較大的。所以如果你細(xì)看一下 CRI，你會(huì)發(fā)現(xiàn)它其實(shí)定了一些非常普遍的操作容器接口。

在這里，我可以把 CRI 大致它分為 Container 和 Sandbox。Sandbox 用來描述的是我通過什么樣的機(jī)制來去實(shí)現(xiàn) Pod ，所以它其實(shí)就是 Pod這個(gè)概念真正跟容器項(xiàng)目相關(guān)的字段。對(duì)于 Docker 或 Linux 容器來說，它其實(shí) match 到最后 run 起來的是一個(gè)叫 infra container 的容器，就是一個(gè)極小的容器，這個(gè)容器用來 hold 整個(gè) Pod 的 Node 和 Namespace。

不過， Kubernetes 如果用 Linux Container Runtim， 比如 Docker 的話，它不會(huì)給你提供 Pod level 的 isolation，除了一層 Pod level cgroups 。這是一個(gè)不同點(diǎn)。因?yàn)椋绻阌?KataContainers 的話，KataContaniners 會(huì)在這一步為你創(chuàng)建一個(gè)輕量級(jí)的虛擬機(jī)。

接下來到下一階段，到 Containers 這個(gè) API 的時(shí)候，對(duì)于 Docker 來說它就給你起在宿主機(jī)上啟動(dòng)用戶容器，但對(duì) Kata 來說不是這樣的，它會(huì)在前面的 Pod 對(duì)應(yīng)的輕量級(jí)虛擬機(jī)里面，也就在前面創(chuàng)建的 Sandbox 里面 set up 這些用戶容器所需要 Namespace ，而不會(huì)再跟你在一起新的容器。所以有了這樣一個(gè)機(jī)制之后，當(dāng)上面 Contol Panel 完成它的工作之后，它說我把 Pod 調(diào)度好了，這時(shí)候 Kubelet 這邊啟動(dòng)或創(chuàng)建這個(gè) Pod 的時(shí)候一路走下去，最后一步才會(huì)去 call 我們這個(gè)所謂 CRI。在此之前，在 Kubelet 或者 Kubernetes 這是沒有所謂 Containers runtime 這個(gè)概念的。

所以走到這一步之后，如果你用 Docker 的話，那么 Kubernetes 里負(fù)責(zé)響應(yīng)這個(gè) CRI 請(qǐng)求 是 Dockershim。但如果你用的不是 Docker 的話一律都要去走一個(gè)叫 remote 的模式，就是你需要寫一個(gè) CRI Shim，去 serve 這個(gè) CRI 請(qǐng)求，這就是我們今天所討論下一個(gè)主題。

?

CRI Shim 如何工作？

CRI Shim 可以做什么？它可以把 CRI 請(qǐng)求 翻譯成 Runtime ?API。我舉個(gè)例子，比如說現(xiàn)在有個(gè) Pod 里有一個(gè) A 容器和有個(gè) B 容器，這時(shí)候我們把這件事提交給 Kubernetes 之后，在 Kubelet 那一端發(fā)起的 CRI code 大概是這樣的序列：首先它會(huì) run Sandbox foo，如果是 Docker 它會(huì)起一個(gè) infra 容器，就是一個(gè)很小的容器叫 foo，如果是 Kata 它會(huì)給你起一個(gè)虛擬機(jī)叫 foo，這是不一樣的。

所以接下來你 creat start container A 和 B 的時(shí)候，在 Docker 里面是起兩個(gè)容器，但在 Kata 里面是在我這個(gè)小虛擬機(jī)里面，在這 Sandbox 里面起兩個(gè)小 NameSpace，這是不一樣的。所以你把這一切東西總結(jié)一下，你會(huì)發(fā)現(xiàn) OK，我現(xiàn)在要把 Kata run 在 Kubernetes 里頭，所以我要做工作，在這一步要需要去做這個(gè) CRI shim，我就想辦法給 Kata 作一個(gè) CRI shim。

而我們能夠想到一個(gè)方式，我能不能重用現(xiàn)在的這些 CRI shim。重用現(xiàn)在哪些？比如說 CRI containerd 這個(gè)項(xiàng)目它就是一個(gè) containerd 的 CRI shim，它可以去響應(yīng) CRI 的請(qǐng)求過來，所以接下來我能不能把這些情況翻譯成對(duì) Kata 這些操作，所以這個(gè)是可以的，這也是我們將用一種方式，就是把 KataContainers 接到我的 Containerd 后面。這時(shí)候它的工作原理大概這樣這個(gè)樣子，Containerd 它有一個(gè)獨(dú)特設(shè)計(jì)，就是他會(huì)為每一個(gè) Contaner 起個(gè)叫做 Contained shim。你 run 一下之后你會(huì)看他那個(gè)宿主機(jī)里面，會(huì) run 一片這個(gè) Containerd shim 一個(gè)一個(gè)對(duì)上去。

?

而這時(shí)候由于 Kata 是一個(gè)有 Sandbox 概念的這樣一個(gè) container runtime，所以 Kata 需要去 match 這些 Shim 與 Kata 之間的關(guān)系，所以 Kata 做一個(gè) Katashim。把這些東西對(duì)起來，就把你的 Contained 的處理的方式翻譯成對(duì) kata 的 request，這是我們之前的一個(gè)方式。

但是你能看到這其實(shí)有些問題的，最明顯的一個(gè)問題在于 對(duì) Kata 或 gVisor 來說，他們都是有實(shí)體的 Sandbox 概念的，而有了 Sandbox 概念后，它就不應(yīng)該去再去給他的每一個(gè) Container 啟動(dòng)有一個(gè) shim match 起來，因?yàn)檫@給我們帶來很大的額外性能損耗。我們不希望每一個(gè)容器都去 match 一個(gè) shim，我們希望一個(gè) Sandbox match 一個(gè) shim。

另外，就是你會(huì)發(fā)現(xiàn) CRI 是服務(wù)于 Kubernetes 的，而且它呈現(xiàn)向上匯報(bào)的狀態(tài)，它是幫助 Kubernetes 的，但是它不幫助 Container runtime。所以說當(dāng)你去做這個(gè)集成時(shí)候，你會(huì)發(fā)現(xiàn)尤其對(duì)于 VM gVisor\KataContainer 來說，它與 CRI 的很多假設(shè)或者是 API 的寫法上是不對(duì)應(yīng)的。所以你的集成工作會(huì)比較費(fèi)勁，這是一個(gè)不 match 的狀態(tài)。

?

最后一個(gè)就是我們維護(hù)起來非常困難，因?yàn)橛捎谟辛?CRI 之后，比如 RedHat 擁有自己的 CRI 實(shí)現(xiàn)叫 cri-o，他們和 containerd 在本質(zhì)上沒有任何區(qū)別，跑到最后都是靠 runC 起容器，為什么要這種東西？

我們不知道，但是我作為 Kata maintainer，我需要給他們兩個(gè)分別寫兩部分的 integration 把 Kata 集成進(jìn)去。這就很麻煩，者就意味著我有 100 種這種 CRI 我就要寫 100 個(gè)集成，而且他們的功能全部都是重復(fù)的。

Containerd ShimV2

所以在今天我給大家 propose 的這個(gè)東西叫做 Containerd ShimV2。前面我們說過 CRI，CRI 決定的是 Runtime 和 Kubernetes 之間的關(guān)系，那么我們現(xiàn)在能不能再有一層更細(xì)致的 API 來決定我的 CRI Shim 跟下面的 Runtime 之間真正的接口是什么樣的？

這就是 ShimV2 出現(xiàn)的原因，它是一層 CRI shim 到 Containerd runtime 之間的標(biāo)準(zhǔn)接口，所以前面我直接從 CRI 到 Containerd 到 runC，現(xiàn)在不是。我們是從 CRI 到 Containerd 到 ShimV2，然后 ShimV2 再到 RunC 再到 KataContainer。這么做有什么好處？

我們來看一下，最大的區(qū)別在于：在這種方式下，你可以為每一個(gè) Pod 指定一個(gè) Shim。因?yàn)樵谧铋_始的時(shí)候，Containerd 是直接啟動(dòng)了一個(gè) Containerd Shim 來去做響應(yīng)，但我們新的 API 是這樣寫的，是 Containerd Shim start 或者 stop。所以這個(gè) start 和 stop 操作怎么去實(shí)現(xiàn)是你要做的事情。

而現(xiàn)在，我作為一位 KataContainers項(xiàng)目的 maintainer 我就可以這么實(shí)現(xiàn)。我在 created Sandbox 的時(shí)候 call 這個(gè) start 的時(shí)候，我啟動(dòng)一個(gè) Containerd Shim。但是當(dāng)我下一步是 call API 的時(shí)候，就前面那個(gè) CRI 里面， Container API 時(shí)候，我就不再起了，我是 reuse，我重用為你創(chuàng)建好的這個(gè) Sandbox，這就位你的實(shí)現(xiàn)提供了很大的自由度。

所以這時(shí)候你會(huì)發(fā)現(xiàn)整個(gè)實(shí)現(xiàn)的方式變了，這時(shí)候 Containerd 用過來之后，它不再去 care 每個(gè)容器起 Containerd Shim，而是由你自己去實(shí)現(xiàn)。我的實(shí)現(xiàn)方式是我只在 Sandbox 時(shí)候，去創(chuàng)建 containerd-shim-v2，而接下來整個(gè)后面的 container level 操作，我會(huì)全部走到這個(gè) containerd-shim-v2 里面，我去重用這個(gè) Sandbox，所以這個(gè)跟前面的時(shí)間就出現(xiàn)很大的不同。

?

所以你現(xiàn)在去總結(jié)一下這個(gè)圖的話，你發(fā)現(xiàn)我們實(shí)現(xiàn)方式是變成這個(gè)樣子：

首先，你還是用原來的 CRI Containerd，只不過現(xiàn)在裝的是 runC，你現(xiàn)在再裝一個(gè) katacontainer 放在那機(jī)器上面。接下來我們 Kata 那邊會(huì)給你寫一個(gè)實(shí)現(xiàn)叫 kata-Containerd-Shimv2。所以前面要寫一大坨 CRI 的東西，現(xiàn)在不用了。現(xiàn)在，我們只 focus 在怎么去把 Containerd 對(duì)接在 kata container 上面，就是所謂的實(shí)現(xiàn) Shimv2 API，這是我們要做的工作。而具體到我們這要做的事情上，其實(shí)它就是這樣一系列與 run 一個(gè)容器相關(guān)的 API。

比如說我可以去 create、start，這些操作全部映射在我 Shimv2 上面去實(shí)現(xiàn)，而不是說我現(xiàn)在考慮怎么去映射，去實(shí)現(xiàn) CRI，這個(gè)自由度由于之前太大，造成了我們現(xiàn)在的一個(gè)局面，就有一堆 CRI Shim 可以用。這其實(shí)是一個(gè)不好的事情。有很多政治原因，有很多非技術(shù)原因，這都不是我們作為技術(shù)人員應(yīng)該關(guān)心的事情，你現(xiàn)在只需要想我怎么去跟 Shimv2 對(duì)接就好了。

接下來，我為你演示一下通過 CRI + containerd shimv2調(diào)用 KataContainers 的一個(gè) Demo（具體內(nèi)容略）

總結(jié)

Kubernetes 現(xiàn)在的核心設(shè)計(jì)思想，就是通過接口化和插件化，將原本復(fù)雜的、對(duì)主干代碼有侵入性的特性，逐一從核心庫(kù)中剝離和解耦。而在這個(gè)過程中，CRI 就是 Kubernetes 項(xiàng)目中最早完成了插件化的一個(gè)調(diào)用接口。而這次分享，主要為你介紹了在CRI基礎(chǔ)上的另一種集成容器運(yùn)行時(shí)的思路，即：CRI + containerd shimv2 的方式。通過這種方式，你就不需要再為自己的容器運(yùn)行時(shí)專門編寫一個(gè) CRI 實(shí)現(xiàn)（CRI shim），而是可以直接重用 containerd對(duì) CRI 的支持能力，然后通過 containerd shimv2的方式來對(duì)接具體的容器運(yùn)行時(shí)（比如 runc）。目前，這種集成方式已經(jīng)成為了社區(qū)對(duì)接下層容器運(yùn)行時(shí)的主流思路，像很多類似于 KataContainers，gVisor，F(xiàn)irecracker 等基于獨(dú)立內(nèi)核或者虛擬化的容器項(xiàng)目，也都開始通過 shimv2 ，進(jìn)而借助 containerd項(xiàng)目無縫接入到 Kubernetes 當(dāng)中。

而眾所周知，在阿里內(nèi)部，Sigma/Kubernetes 系統(tǒng)使用的容器運(yùn)行時(shí)主要是 PouchContainer。事實(shí)上，PouchContainer 本身選擇使用 containerd 作為其主要的容器運(yùn)行時(shí)管理引擎，并自我實(shí)現(xiàn)了增強(qiáng)版的 CRI 接口，使其滿足阿里巴巴強(qiáng)隔離、生產(chǎn)級(jí)別的容器需求。所以在 shimv2 API 在 containerd 社區(qū)發(fā)布之后，PouchContainer 項(xiàng)目就已經(jīng)率先開始探索和嘗試通過 containerd shimv2 來對(duì)接下層的容器運(yùn)行時(shí)，進(jìn)而更高效的完成對(duì)其他種類的容器運(yùn)行時(shí)尤其是虛擬化容器的集成工作。我們知道，自從開源以來，PouchContainer 團(tuán)隊(duì)一直都在積極地推動(dòng) containerd 上游社區(qū)的發(fā)展和演進(jìn)工作，而在這次 CRI + containerd shimv2 的變革里， PouchContainer 再一次走到了各個(gè)容器項(xiàng)目的最前面。