Kubernetes架構簡介

Kubernetes架構如下圖所示：

在這張系統(tǒng)架構圖中，我們把服務分為運行在工作節(jié)點上的服務和組成集群級別控制板的服務。Kubernetes節(jié)點有運行應用容器必備的服務，而這些都是受Master的控制。

每次個節(jié)點上當然都要運行Docker。Docker來負責所有具體的映像下載和容器運行。

Kubernetes主要由以下幾個核心組件組成：

1)etcd保存了整個集群的狀態(tài)；

2)apiserver提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API注冊和發(fā)現等機制；

3)controller manager負責維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；

4)scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；

5)kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網絡（CNI）的管理；

6)Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；

7)kube-proxy負責為Service提供cluster內部的服務發(fā)現和負載均衡；

而和運行時緊密相關的就是kubelet。

kubelet架構

kubelet架構如下圖所示：

kubelet是運行在每個節(jié)點上的主要的“節(jié)點代理”，每個節(jié)點都會啟動kubelet進程，用來處理Master節(jié)點下發(fā)到本節(jié)點的任務，按照PodSpec描述來管理Pod和其中的容器（PodSpec是用來描述一個pod的YAML或者JSON對象）。kubelet通過各種機制（主要通過apiserver）獲取一組PodSpec并保證在這些PodSpec中描述的容器健康運行。

容器運行時接口（CRI）

Kubernetes節(jié)點的底層由一個叫做“容器運行時”的軟件進行支撐，它負責比如啟停容器這樣的事情。最廣為人知的容器運行時當屬Docker，但它不是唯一的。例如最近比較火熱的安全容器KataContainer。所以也就很自然會與有一個需求，就是我們怎么去把KataContainer run在Kubernetes里?

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

對于這個訴求，就關系到Container Runtime Interface，我們叫它CRI。CRI的作用其實只有一個：就是它描述了對于Kubernetes來說，一個Container應該有哪些操作，每個操作有哪些參數，這就是CRI的一個設計原理（本質上是一堆ops）。

Kubelet與容器運行時通信（或者是CRI插件填充了容器運行時）時，Kubelet就像是客戶端，而CRI插件就像對應的服務器。它們之間可以通過Unix套接字或者gRPC框架進行通信。

protocol buffers API包含了兩個gRPC服務：ImageService和RuntimeService。ImageService提供了從鏡像倉庫拉取、查看、和移除鏡像的RPC。RuntimeSerivce包含了Pods和容器生命周期管理的RPC，以及跟容器交互的調用(exec/attach/port-forward)。一個單塊的容器運行時能夠管理鏡像和容器（例如：Docker和Rkt），并且通過同一個套接字同時提供這兩種服務。這個套接字可以在Kubelet里通過標識–container-runtime-endpoint和–image-service-endpoint進行設置。

下圖顯示了ImageService和RuntimeService具體需要實現哪些接口。

CRI Shim

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

所以接下來你creat start container A和B的時候，在Docker里面是起兩個容器，但在Kata里面是在我這個小虛擬機里面，在這Sandbox里面起兩個小NameSpace，這是不一樣的。所以你把這一切東西總結一下，你會發(fā)現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。

另外，就是你會發(fā)現CRI是服務于Kubernetes的，而且它呈現向上匯報的狀態(tài)，它是幫助Kubernetes的，但是它不幫助Container runtime。所以說當你去做這個集成時候，你會發(fā)現尤其對于VM gVisorKataContainer來說，它與CRI的很多假設或者是API的寫法上是不對應的。所以你的集成工作會比較費勁，這是一個不match的狀態(tài)。

最后一個就是我們維護起來非常困難，因為由于有了CRI之后，比如RedHat擁有自己的CRI實現叫cri-o（基于Open Container Initiative的Kubernetes Container Runtime Interface的實現），他們和containerd在本質上沒有任何區(qū)別，跑到最后都是靠runC起容器，為什么要這種東西？

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

Containerd ShimV2

為了解決以上的shim問題，引入了shimv2。前面我們說過CRI，CRI決定的是Runtime和Kubernetes之間的關系，那么我們現在能不能再有一層更細致的API來決定我的CRI Shim跟下面的Runtime之間真正的接口是什么樣的？

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

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

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

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

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

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

容器運行時總結

下圖顯示了當前主要的容器運行時和主要維護者。