Kubernetes架構(gòu)簡(jiǎn)介

Kubernetes架構(gòu)如下圖所示：

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

每次個(gè)節(jié)點(diǎn)上當(dāng)然都要運(yùn)行Docker。Docker來(lái)負(fù)責(zé)所有具體的映像下載和容器運(yùn)行。

Kubernetes主要由以下幾個(gè)核心組件組成：

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

2)apiserver提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制；

3)controller manager負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等；

4)scheduler負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；

5)kubelet負(fù)責(zé)維護(hù)容器的生命周期，同時(shí)也負(fù)責(zé)Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理；

6)Container runtime負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI）；

7)kube-proxy負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；

而和運(yùn)行時(shí)緊密相關(guān)的就是kubelet。

kubelet架構(gòu)

kubelet架構(gòu)如下圖所示：

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

容器運(yùn)行時(shí)接口（CRI）

Kubernetes節(jié)點(diǎn)的底層由一個(gè)叫做“容器運(yùn)行時(shí)”的軟件進(jìn)行支撐，它負(fù)責(zé)比如啟停容器這樣的事情。最廣為人知的容器運(yùn)行時(shí)當(dāng)屬Docker，但它不是唯一的。例如最近比較火熱的安全容器KataContainer。所以也就很自然會(huì)與有一個(gè)需求，就是我們?cè)趺慈グ袺ataContainer run在Kubernetes里?

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

對(duì)于這個(gè)訴求，就關(guān)系到Container Runtime Interface，我們叫它CRI。CRI的作用其實(shí)只有一個(gè)：就是它描述了對(duì)于Kubernetes來(lái)說(shuō)，一個(gè)Container應(yīng)該有哪些操作，每個(gè)操作有哪些參數(shù)，這就是CRI的一個(gè)設(shè)計(jì)原理（本質(zhì)上是一堆ops）。

Kubelet與容器運(yùn)行時(shí)通信（或者是CRI插件填充了容器運(yùn)行時(shí)）時(shí)，Kubelet就像是客戶端，而CRI插件就像對(duì)應(yīng)的服務(wù)器。它們之間可以通過(guò)Unix套接字或者gRPC框架進(jìn)行通信。

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

下圖顯示了ImageService和RuntimeService具體需要實(shí)現(xiàn)哪些接口。

CRI Shim

CRI Shim可以做什么？它可以把CRI請(qǐng)求 翻譯成Runtime API。我舉個(gè)例子，比如說(shuō)現(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，這是不一樣的。

所以接下來(lái)你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)在哪些？比如說(shuō)CRI containerd這個(gè)項(xiàng)目它就是一個(gè)containerd的CRI shim，它可以去響應(yīng)CRI的請(qǐng)求過(guò)來(lái)，所以接下來(lái)我能不能把這些情況翻譯成對(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ì)起來(lái)，就把你的Contained的處理的方式翻譯成對(duì)kata的request，這是我們之前的一個(gè)方式。

但是你能看到這其實(shí)有些問(wèn)題的，最明顯的一個(gè)問(wèn)題在于對(duì)Kata或gVisor來(lái)說(shuō)，他們都是有實(shí)體的Sandbox概念的，而有了Sandbox概念后，它就不應(yīng)該去再去給他的每一個(gè)Container啟動(dòng)有一個(gè)shim match起來(lái)，因?yàn)檫@給我們帶來(lái)很大的額外性能損耗。我們不希望每一個(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。所以說(shuō)當(dāng)你去做這個(gè)集成時(shí)候，你會(huì)發(fā)現(xiàn)尤其對(duì)于VM gVisorKataContainer來(lái)說(shuō)，它與CRI的很多假設(shè)或者是API的寫法上是不對(duì)應(yīng)的。所以你的集成工作會(huì)比較費(fèi)勁，這是一個(gè)不match的狀態(tài)。

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

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

Containerd ShimV2

為了解決以上的shim問(wèn)題，引入了shimv2。前面我們說(shuō)過(guò)CRI，CRI決定的是Runtime和Kubernetes之間的關(guān)系，那么我們現(xiàn)在能不能再有一層更細(xì)致的API來(lái)決定我的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)樵谧铋_(kāi)始的時(shí)候，Containerd是直接啟動(dòng)了一個(gè)Containerd Shim來(lái)去做響應(yīng)，但我們新的API是這樣寫的，是Containerd Shim start或者stop。所以這個(gè)start和stop操作怎么去實(shí)現(xiàn)是你要做的事情。

例如KataContainers項(xiàng)目可以這么實(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用過(guò)來(lái)之后，它不再去care每個(gè)容器起Containerd Shim，而是由你自己去實(shí)現(xiàn)。我的實(shí)現(xiàn)方式是我只在Sandbox時(shí)候，去創(chuàng)建containerd-shim-v2，而接下來(lái)整個(gè)后面的container level操作，我會(huì)全部走到這個(gè)containerd-shim-v2里面，我去重用這個(gè)Sandbox，所以這個(gè)跟前面的時(shí)間就出現(xiàn)很大的不同。如下圖所示是Kata1.5中采用shim v2的實(shí)現(xiàn)。

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

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

容器運(yùn)行時(shí)總結(jié)

下圖顯示了當(dāng)前主要的容器運(yùn)行時(shí)和主要維護(hù)者。