Kubernetes架構簡介

Kubernetes架構如下圖所示：

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

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

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

1)etcd保存了整個集群的狀態；

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

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

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

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

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

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

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

kubelet架構

kubelet架構如下圖所示：

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

容器運行時接口（CRI）

Kubernetes節點的底層由一個叫做“容器運行時”的軟件進行支撐，它負責比如啟停容器這樣的事情。最廣為人知的容器運行時當屬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那一端發起的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 gVisorKataContainer來說，它與CRI的很多假設或者是API的寫法上是不對應的。所以你的集成工作會比較費勁，這是一個不match的狀態。

最后一個就是我們維護起來非常困難，因為由于有了CRI之后，比如RedHat擁有自己的CRI實現叫cri-o（基于Open Container Initiative的Kubernetes Container Runtime Interface的實現），他們和containerd在本質上沒有任何區別，跑到最后都是靠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。這么做有什么好處？

最大的區別在于：在這種方式下，你可以為每一個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，我重用為你創建好的這個Sandbox，這就位你的實現提供了很大的自由度。

所以這時候你會發現整個實現的方式變了，這時候Containerd用過來之后，它不再去care每個容器起Containerd Shim，而是由你自己去實現。我的實現方式是我只在Sandbox時候，去創建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對接就好了。

容器運行時總結

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