CRI + shimv2： 一種 Kubernetes？

　　Kubernetes 專案目前的重點發展方向，是為開發者和使用者暴露更多的介面和可擴充套件機制，將更多的使用者需求下放到社群來完成。其中，發展最為成熟也最為重要的一個介面就是 CRI。2018 年，由 containerd 社群主導的 shimv2 API 的出現，在 CRI 的基礎上，為使用者整合自己的容器執行時帶來了更加成熟和方便的實踐方法。

　　本次演講分享了關於 Kubernetes 介面化設計、CRI、容器執行時、shimv2、RuntimeClass 等關鍵技術特性的設計與實現，並以 KataContainers 為例，為聽眾演示上述技術特性的使用方法。本文整理自張磊在 KubeCon + CloudNativeCon 2018 現場的演講速記。

　　張磊

　　阿里巴巴高階技術專家

　　Kubernetes 社群資深成員與專案維護者

　　張磊，阿里集團高階技術專家，Kubernetes 專案資深成員和聯合維護者。主要關注容器執行時介面(CRI)、排程、資源管理和基於虛擬化技術的容器執行時等特性，共同負責 Kubernetes 上游和阿里集團大型叢集管理系統的工程工作。張磊曾就職於微軟研究院(MSR)和 KataContainers 團隊，也是 KubeCon 大會上備受歡迎的演講者。

　　今天，我給大家帶來的分享是關於 Containerd+KataContainers+Kubernetes 的用法和整合。大家好，我是張磊，現在在阿里巴巴集團工作。既然今天我們們會聊 Kubernetes 這個專案，那麼首先我們來簡單看一下 Kubernetes 這個專案的工作原理。

　　Kubernetes 工作原理

　　其實大家都知道 Kubernetes 這個專案它最上面是一層 Control Panel ，它也被很多人稱之為 Master 節點。當你把 workload 就是你的應用提交給 Kubernetes 之後，首先為你做事情的是 API server，它會把你的 Application 存到 etcd 裡，以 API 物件的方式存到 etcd 中去。

　　而 Kubernetes 中負責編排的是 Controller manager，一堆 controller 透過控制迴圈在 run。透過這個控制迴圈來做編排工作，幫你去建立出這些應用所需要的 Pod，注意不是容器，是 Pod。

　　而一旦一個 Pod 出現之後，Scheduler 會 watch 新 Pod 的變化。如果他發現有一個新的 Pod 出現，Scheduler 會幫你去把所有排程演算法都 run 一遍，把 run 到的結果：就是一個 Node 的名字，寫在我這個 Pod 物件 NodeName 欄位上面，就是一個所謂的 bind 的操作。

　　然後把 bind 的結果寫回到 etcd 裡去，這就是所謂的 Scheduler 工作過程。所以 Control Panel 它忙活這麼一圈下來，最後得到的結果是什麼呢?你的一個 Pod 跟一個 Node 繫結(bind)在了一起，就是所謂 Schedule 了。

　　而 Kubelet 呢?它是執行在所有節點上。Kubelet 會 watch 所有 Pod 物件的變化，當它發現一個 Pod 與一個 Node 繫結在一起的時，並且它又發現這個被繫結的 Node 是它自己，那麼 Kubelet 就會幫你去接管接下來的所有事情。

　　如果你看一下 Kubelet ，看看它在做什麼呢?很簡單，其實當 Kubelet 拿到這個資訊之後，他是去 call 你執行在每個機器上的 Containerd 程式，去 run 這個 Pod 裡的每一個容器。

　　這時候，Containerd 幫你去 call runC 所以最後其實是 runC 幫你去 set up 起來這些 namespace、Cgroup 這些東西，是它去幫你 chroot ，“搭”出來所謂的一個應用和需要的容器。這就是整個 Kubernetes 工作的一個簡單原理。

　　Linux Container

　　所以這個時候你可能會提出一個問題就是什麼是容器?其實容器非常簡單，我們平常所說這個容器就是 Linux 容器，你可以把 Linux 容器分為兩部分：第一個是 Container Runtime，第二個是 Container Image。

　　所謂的 Runtime 部分就是你所執行程式的動態檢視和資源邊界，所以它是由 Namespace 和 Cgroup 為你構建出來的。而對於 Image(映象)，你可以把它理解為是你想要執行的程式的靜態檢視，所以它其實是你的程式+資料+所有的依賴+所有的目錄檔案組成一個壓縮包而已。

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

　　KataContainer

　　可今天我們還要聊另外一種 Container，它與前面 Linux Container 截然不同。他的 Container Runtime 是用 hypervisor 實現的，是用 hardware virtualization 實現的，像個虛擬機器一樣。所以每一個像這樣的 KataContainer 的 Pod，都是一個輕量級虛擬機器，它是有完整的 Linux 核心。

　　所以我們經常說 KataContainer 與 VM 一樣能提供強隔離性，但由於它的最佳化和效能設計，它擁有與容器項媲美的敏捷性。這個一點稍後會強調，而對於映象部分， KataContainer 與 Docker 這些專案沒有任何不同，它使用的是標準 Linux Continer 容器，支援標準的 OCR Image 所以這一部分是完全一樣的。

　　容器安全

　　可是你可能會問為什麼我們會有 KataContainer 這種專案? 其實很簡單，因為我們關心安全這個事，比如很多金融的場景、加密的場景，甚至現在區塊鏈很多場景下，都需要一個安全的 Container Runtime，所以這是我們強調 KataContainer 的一個原因。

　　如果你現在正在使用 Docker， 我問一個問題就是你怎樣才能安全地使用 Docker?你可能會有很多套路去做。比如說你會 drop 掉一些 Linux capibility，你可以去指定 Runtime 可以做什麼，不能做什麼。

　　第二個你可以去 read-only mount points 。第三，你可以使用 SELinux 或者 AppArmor 這些工具把容器給保護起來。還有一種方式是可以直接拒絕一些 syscalls，可以用到 SECCOMP。

　　但是我需要強調的是所有這些操作都會在你的 Container 和 Host 之間引入新的 layer，因為它要去做過濾，它要去攔截你的 syscalls，所以這個部分你搭的層越多，你容器效能越差，它一定是有額外的負面效能損耗的。

　　更重要的是,做這些事情之前你要想清楚到底應該幹什麼，到底應該 drop 掉哪些 syscalls，這個是需要具體問題具體分析的，那麼這時候我應該怎麼去跟我的使用者去講如何做這件事情?

　　所以，這些事情說起來很簡單，但實際執行起來很少有人知道到底該怎麼去做。所以在 99.99% 的情況下，大多數人都是把容器 run 到虛擬機器裡去的，尤其在公有云場景下。

　　而對於 KataContainer 這種專案來說，它由於使用了與虛擬機器一樣的 hardware virualization，它是有獨立核心的，所以這個時候它提供的 isolation 是完全可信任的，就與你信任 VM 是一樣的。

　　更重要的是，由於現在每一個 Pod 裡是有一個 Independent Kernel，跟個小虛擬機器一樣，所以這時候就允許你容器執行的 Kernel 版本跟 Host machine 適應是完全不一樣。

　　這是完全 OK 的，就與你在在虛擬機器中做這件事一樣，所以這就是為什麼我會強調 KataContainers 的一個原因，因為它提供了安全和多租戶的能力。

　　Kubernetes + 安全容器

　　所以也就很自然會與有一個需求，就是我們怎麼去把 KataContainer run 在 Kubernetes 裡?

　　那麼這個時候我們還是先來看 Kubelet 在做什麼事情，所以 Kubelet 要想辦法像 call Containerd 一樣去 call KataContainer，然後由 KataContainer 負責幫忙把 hypervisor 這些東西 set up 起來，幫我把這個小 VM 執行起來。所以這個時候就要需要想怎麼讓 Kubernetes 能合理的操作 KataContainers。

　　Container Runtime Interface(CRI)

　　對於這個訴求，就關係到了我們之前一直在社群推進的 Container Runtime Interface ，我們叫它 CRI。

　　CRI 的作用其實只有一個：就是它描述了，對於 Kubernetes 來說，一個 Container 應該有哪些操作，每個操作有哪些引數，這就是 CRI 的一個設計原理。但需要注意的是，CRI 是一個以容器為核心的 API，它裡面沒有 Pod 的這個概念。這個要記住。

　　為什麼這麼說呢?我們為什麼要這麼設計呢?很簡單，我們不希望像 Docker 這樣的專案，必須得懂什麼是 Pod，暴露出 Pod 的 API，這是不合理的訴求。Pod 永遠都是一個 Kubernetes 的編排概念，這跟容器沒有關係，所以這就是為什麼我們要把這個 API 做成 Containerd -centric。

　　另外一個原因出於 maintain 的考慮，因為如果現在， CRI 裡有 Pod 這個概念，那麼接下來任何一個 Pod feature 的變更都有可能會引起 CRI 的變動，對於一個介面來說，這樣的維護代價是比較大的。所以如果你細看一下 CRI，你會發現它其實定了一些非常普遍的操作容器介面。

　　在這裡，我可以把 CRI 大致它分為 Container 和 Sandbox。Sandbox 用來描述的是我透過什麼樣的機制來去實現 Pod ，所以它其實就是 Pod這個概念真正跟容器專案相關的欄位。對於 Docker 或 Linux 容器來說，它其實 match 到最後 run 起來的是一個叫 infra container 的容器，就是一個極小的容器，這個容器用來 hold 整個 Pod 的 Node 和 Namespace。

　　不過， Kubernetes 如果用 Linux Container Runtim， 比如 Docker 的話，它不會給你提供 Pod level 的 isolation，除了一層 Pod level cgroups 。這是一個不同點。因為，如果你用 KataContainers 的話，KataContaniners 會在這一步為你建立一個輕量級的虛擬機器。

　　接下來到下一階段，到 Containers 這個 API 的時候，對於 Docker 來說它就給你起在宿主機上啟動使用者容器，但對 Kata 來說不是這樣的，它會在前面的 Pod 對應的輕量級虛擬機器裡面，也就在前面建立的 Sandbox 裡面 set up 這些使用者容器所需要 Namespace ，而不會再跟你在一起新的容器。

　　所以有了這樣一個機制之後，當上面 Contol Panel 完成它的工作之後，它說我把 Pod 排程好了，這時候 Kubelet 這邊啟動或建立這個 Pod 的時候一路走下去，最後一步才會去 call 我們這個所謂 CRI。在此之前，在 Kubelet 或者 Kubernetes 這是沒有所謂 Containers runtime 這個概念的。

　　所以走到這一步之後，如果你用 Docker 的話，那麼 Kubernetes 裡負責響應這個 CRI 請求 是 Dockershim。但如果你用的不是 Docker 的話一律都要去走一個叫 remote 的模式，就是你需要寫一個 CRI Shim，去 serve 這個 CRI 請求，這就是我們今天所討論下一個主題。

　　CRI Shim 如何工作?

　　CRI Shim 可以做什麼?它可以把 CRI 請求 翻譯成 Runtime API。我舉個例子，比如說現在有個 Pod 裡有一個 A 容器和有個 B 容器，這時候我們把這件事提交給 Kubernetes 之後，在 Kubelet 那一端發起的 CRI code 大概是這樣的序列：首先它會 run Sandbox foo，如果是 Docker 它會起一個 infra 容器，就是一個很小的容器叫 foo，如果是 Kata 它會給你起一個虛擬機器叫 foo，這是不一樣的。

　　所以接下來你 creat start container A 和 B 的時候，在 Docker 裡面是起兩個容器，但在 Kata 裡面是在我這個小虛擬機器裡面，在這 Sandbox 裡面起兩個小 NameSpace，這是不一樣的。

　　所以你把這一切東西總結一下，你會發現 OK，我現在要把 Kata run 在 Kubernetes 裡頭，所以我要做工作，在這一步要需要去做這個 CRI shim，我就想辦法給 Kata 作一個 CRI shim。

　　而我們能夠想到一個方式，我能不能重用現在的這些 CRI shim。重用現在哪些?比如說 CRI containerd 這個專案它就是一個 containerd 的 CRI shim，它可以去響應 CRI 的請求過來，所以接下來我能不能把這些情況翻成對 Kata 這些操作，所以這個是可以的，這也是我們將用一種方式，就是把 KataContainers 接到我的 Containerd 後面。

　　這時候它的工作原理大概這樣這個樣子，Containerd 它有一個獨特設計，就是他會為每一個 Contaner 起個叫做 Contained shim。你 run 一下之後你會看他那個宿主機裡面，會 run 一片這個 Containerd shim 一個一個對上去。

　　而這時候由於 Kata 是一個有 Sandbox 概念的這樣一個 container runtime，所以 Kata 需要去 match 這些 Shim 與 Kata 之間的關係，所以 Kata 做一個 Katashim。把這些東西對起來，就把你的 Contained 的處理的方式翻譯成對 kata 的 request，這是我們之前的一個方式。

　　但是你能看到這其實有些問題的，最明顯的一個問題在於 對 Kata 或 gVisor 來說，他們都是有實體的 Sandbox 概念的，而有了 Sandbox 概念後，它就不應該去再去給他的每一個 Container 啟動有一個 shim match 起來，因為這給我們帶來很大的額外效能損耗。我們不希望每一個容器都去 match 一個 shim，我們希望一個 Sandbox match 一個 shim。

　　另外，就是你會發現 CRI 是服務於 Kubernetes 的，而且它呈現向上彙報的狀態，它是幫助 Kubernetes 的，但是它不幫助 Container runtime。所以說當你去做這個整合時候，你會發現尤其對於 VM gVisor\KataContainer 來說，它與 CRI 的很多假設或者是 API 的寫法上是不對應的。所以你的整合工作會比較費勁，這是一個不 match 的狀態。

　　最後一個就是我們維護起來非常困難，因為由於有了 CRI 之後，比如 RedHat 擁有自己的 CRI 實現叫 cri-o，他們和 containerd 在本質上沒有任何區別，跑到最後都是靠 runC 起容器，為什麼要這種東西?

　　我們不知道，但是我作為 Kata maintainer，我需要給他們兩個分別寫兩部分的 integration 把 Kata 整合進去。這就很麻煩，者就意味著我有 100 種這種 CRI 我就要寫 100 個整合，而且他們的功能全部都是重複的。

　　Containerd ShimV2

　　所以在今天我給大家 propose 的這個東西叫做 Containerd ShimV2。前面我們說過 CRI，CRI 決定的是 Runtime 和 Kubernetes 之間的關係，那麼我們現在能不能再有一層更細緻的 API 來決定我的 CRI Shim 跟下面的 Runtime 之間真正的介面是什麼樣的?

　　這就是 ShimV2 出現的原因，它是一層 CRI shim 到 Containerd runtime 之間的標準介面，所以前面我直接從 CRI 到 Containerd 到 runC，現在不是。我們是從 CRI 到 Containerd 到 ShimV2，然後 ShimV2 再到 RunC 再到 KataContainer。這麼做有什麼好處?

　　我們來看一下，最大的區別在於：在這種方式下，你可以為每一個 Pod 指定一個 Shim。因為在最開始的時候，Containerd 是直接啟動了一個 Containerd Shim 來去做響應，但我們新的 API 是這樣寫的，是 Containerd Shim start 或者 stop。所以這個 start 和 stop 操作怎麼去實現是你要做的事情。

　　而現在，我作為一位 KataContainers 專案的 maintainer 我就可以這麼實現。我在 created Sandbox 的時候 call 這個 start 的時候，我啟動一個 Containerd Shim。但是當我下一步是 call API 的時候，就前面那個 CRI 裡面， Container API 時候，我就不再起了，我是 reuse，我重用為你建立好的這個 Sandbox，這就位你的實現提供了很大的自由度。

　　所以這時候你會發現整個實現的方式變了，這時候 Containerd 用過來之後，它不再去 care 每個容器起 Containerd Shim，而是由你自己去實現。我的實現方式是我只在 Sandbox 時候，去建立 containerd-shim-v2，而接下來整個後面的 container level 操作，我會全部走到這個 containerd-shim-v2 裡面，我去重用這個 Sandbox，所以這個跟前面的時間就出現很大的不同。

　　所以你現在去總結一下這個圖的話，你發現我們實現方式是變成這個樣子：

　　首先，你還是用原來的 CRI Containerd，只不過現在裝的是 runC，你現在再裝一個 katacontainer 放在那機器上面。接下來我們 Kata 那邊會給你寫一個實現叫 kata-Containerd-Shimv2。所以前面要寫一大坨 CRI 的東西，現在不用了。

　　現在，我們只 focus 在怎麼去把 Containerd 對接在 kata container 上面，就是所謂的實現 Shimv2 API，這是我們要做的工作。而具體到我們這要做的事情上，其實它就是這樣一系列與 run 一個容器相關的 API。

　　比如說我可以去 create、start，這些操作全部對映在我 Shimv2 上面去實現，而不是說我現在考慮怎麼去對映，去實現 CRI，這個自由度由於之前太大，造成了我們現在的一個局面，就有一堆 CRI Shim 可以用。這其實是一個不好的事情。有很多政治原因，有很多非技術原因，這都不是我們作為技術人員應該關心的事情，你現在只需要想我怎麼去跟 Shimv2 對接就好了。

　　接下來，我為你演示一下透過 CRI + containerd shimv2 呼叫 KataContainers 的一個 Demo(具體內容略)

　　總結

　　Kubernetes 現在的核心設計思想，就是透過介面化和外掛化，將原本複雜的、對主幹程式碼有侵入性的特性，逐一從核心庫中剝離和解耦。而在這個過程中，CRI 就是 Kubernetes 專案中最早完成了外掛化的一個呼叫介面。

　　而這次分享，主要為你介紹了在CRI基礎上的另一種整合容器執行時的思路，即：CRI + containerd shimv2 的方式。透過這種方式，你就不需要再為自己的容器執行時專門編寫一個 CRI 實現(CRI shim)，而是可以直接重用 containerd 對 CRI 的支援能力，然後透過 containerd shimv2 的方式來對接具體的容器執行時(比如 runc)。

　　目前，這種整合方式已經成為了社群對接下層容器執行時的主流思路，像很多類似於 KataContainers，gVisor，Firecracker 等基於獨立核心或者虛擬化的容器專案，也都開始透過 shimv2 ，進而藉助 containerd 專案無縫接入到 Kubernetes 當中。

　　事實上，PouchContainer 本身選擇使用 containerd 作為其主要的容器執行時管理引擎，並實現了增強版的 CRI 介面，使其滿足阿里巴巴強隔離、生產級別的容器需求。

　　所以在 shimv2 API 在 containerd 社群釋出之後，PouchContainer 專案就已經率先開始探索和嘗試透過 containerd shimv2 來對接下層的容器執行時，進而更高效的完成對其他種類的容器執行時尤其是虛擬化容器的整合工作。

　　我們知道，自從開源以來，PouchContainer 團隊一直都在積極地推動 containerd 上游社群的發展和演進工作，而在這次 CRI + containerd shimv2 的變革裡， PouchContainer 再一次走到了各個容器專案的最前面。

：

：

：