1. 定義
1.1 SIG-Node
是要給Kubernetes的一個(gè)小組漩勤，負(fù)責(zé)kubelet和容器運(yùn)行時(shí)管理（本來(lái)以為他是個(gè)組件或機(jī)制之類的涡匀。。沃斤。）圣蝎。雖然這個(gè)小組相對(duì)比較沉寂不太發(fā)聲，但它所負(fù)責(zé)的模塊是Kuberetes整套體系中非常核心的部分衡瓶。
kubelet的工作原理
image
SyncLoop本身要求這個(gè)控制循環(huán)是絕對(duì)不可以被阻塞的徘公，（這家伙一阻塞，那么這個(gè)node上后續(xù)所有的pod等操作就直接跟著pending了）哮针，所以SyncLoop都會(huì)開啟單獨(dú)的goroutine（可以開始慢慢涉及代碼了）來(lái)操作的关面。
1.2 CRI
CRI（Container Runtime Interface），容器運(yùn)行時(shí)接口十厢，是gRPC接口等太，是kubelet調(diào)用下層容器運(yùn)行時(shí)的時(shí)候調(diào)用的接口。是為了屏蔽Kubernetes項(xiàng)目對(duì)容器運(yùn)行時(shí)的感知蛮放，因?yàn)槿萜鬟\(yùn)行時(shí)是多種多樣的缩抡，Docker之外，還有加入Kubernetes其中的rkt包颁，以及前隔離容器runV瞻想，如果不加這一層CRI的話，像1.6版本之前的Kubernetes一樣徘六，直接調(diào)用容器運(yùn)行時(shí)的API來(lái)創(chuàng)建和管理容器的話内边，當(dāng)對(duì)接多個(gè)容器運(yùn)行時(shí)，則對(duì)kubelet的代碼周期維護(hù)會(huì)造成極大的壓力待锈。
2016年，SIG-Node通過(guò)將kubelet對(duì)容器的操作嘴高，統(tǒng)一地抽象成一個(gè)接口竿音，具體的接口實(shí)現(xiàn)，由各個(gè)容器運(yùn)行時(shí)來(lái)實(shí)現(xiàn)拴驮。
而這一層容器操作的接口春瞬，就是CRI。
當(dāng)CRI被提出后套啤，Kubernetes及kubelet本身的架構(gòu)宽气，就可以用如下的接口圖來(lái)描述了。
當(dāng)Kubernetes通過(guò)編排能力創(chuàng)建了一個(gè)Pod之后潜沦，調(diào)度器會(huì)為這個(gè)Pod選擇一個(gè)具體的節(jié)點(diǎn)來(lái)運(yùn)行萄涯。這個(gè)時(shí)候，kubelet當(dāng)然就會(huì)通過(guò)SyncLoop來(lái)判斷需要進(jìn)行的操作唆鸡，比如創(chuàng)建一個(gè)Pod涝影。kubelet之后就會(huì)調(diào)用一個(gè)叫做GenericRuntime的通用組件來(lái)發(fā)起一個(gè)創(chuàng)建一個(gè)Pod的CRI grpc請(qǐng)求。如果使用的容器項(xiàng)目是Docker的話争占，會(huì)有一個(gè)叫做dockershim的組件燃逻，接收到CRI請(qǐng)求并解析后序目，組裝成一個(gè)Docker API請(qǐng)求發(fā)送給Docker Daemon。
但是更為普適的場(chǎng)景是伯襟，在每臺(tái)宿主機(jī)上安裝一個(gè)負(fù)責(zé)響應(yīng)CRI請(qǐng)求的組件猿涨，這個(gè)組件（也可以叫做CRI shim），來(lái)扮演kubelet和各個(gè)容器項(xiàng)目之間的shim姆怪。具體來(lái)說(shuō)就是實(shí)現(xiàn)CRI抽象接口的和具體容器運(yùn)行時(shí)間的接口參數(shù)“翻譯”和請(qǐng)求叛赚。
1.3 容器運(yùn)行時(shí)
舉例
- rkt（CoreOS）
- Docker
- runV-基于虛擬化技術(shù)的強(qiáng)隔離容器
2. CRI設(shè)計(jì)與實(shí)現(xiàn)原理
正如1中描述，CRI定義了一系列kubelet操作各種容器運(yùn)行時(shí)的接口片效，之后容器運(yùn)行時(shí)各自實(shí)現(xiàn)接口红伦，完成對(duì)容器運(yùn)行時(shí)的相關(guān)操作。
除了Docker shim是內(nèi)嵌在kubelet之中之外淀衣，其他的CRI shim都需要在node上各自實(shí)現(xiàn)和安裝昙读。
2.1 CRI的接口定義
下圖是CRI里主要的待實(shí)現(xiàn)接口（好吧，我會(huì)去看源碼的https://github.com/kubernetes/kubernetes/tree/release-1.13）
CRI的接口類型可以分為兩組
- RunTimeService膨桥，提供和容器操作相關(guān)的interface蛮浑。如創(chuàng)建和啟動(dòng)容器、刪除容器只嚣，執(zhí)行exec命令等
- ImageService沮稚，提供容器鏡像相關(guān)的操作，比如拉取和刪除鏡像册舞。
2.2 RuntimeService
CRI設(shè)計(jì)的一個(gè)重要原則就是確保這個(gè)接口本身蕴掏，只關(guān)注容器，不關(guān)注POD调鲸。
- Pod是Kubernetes的編排概念盛杰，而不是容器運(yùn)行時(shí)的概念。所以我們不能假設(shè)所有的下層容器項(xiàng)目藐石，都能夠暴露出可以直接映射為Pod的API即供。
- 如果在CRI中引入的Pod的概念，那么接下來(lái)只要Pod API對(duì)象的字段發(fā)生變化于微，那么CRI很可能就需要變更逗嫡。
那么，CRI存在既然是翻譯kubelet對(duì)docker操作的株依，那就避免不了是通過(guò)Pod API對(duì)象的yaml文件進(jìn)行解析驱证，那么CRI怎么既不引Pod概念又能夠把kubelet對(duì)docker的操作從yaml文件中翻譯成docker指令的？比如通過(guò)kubetcl run去手動(dòng)起一個(gè)包含兩個(gè)容器的Pod foo時(shí)勺三，CRI做了啥事情呢雷滚？
可以看到CRI的主要接口中，是有一個(gè)RunPodSandbox的interface的吗坚，這個(gè)Interface實(shí)際獲取到的是Pod中一部分與容器運(yùn)行時(shí)相關(guān)的字段祈远，比如Hostname呆万、DnsConfig、CgroupParent等字段车份。至于這些字段要如何使用谋减，就得看各個(gè)容器的CRI shim是如何根據(jù)自身的特性來(lái)通過(guò)這些字段實(shí)現(xiàn)Kubernetes所希望的Pod的狀態(tài)。
上面提到的kubectl run的例子扫沼，當(dāng)請(qǐng)求通過(guò)編排之后出爹，到達(dá)了某個(gè)node的kubelet之后，kubelet就會(huì)按照下圖所示的順序來(lái)調(diào)用CRI的接口缎除。
正如前面提到的严就，不同的容器的CRI shim的實(shí)現(xiàn)是不通的，
- 如果是Docker容器器罐，dockshim會(huì)創(chuàng)建出一個(gè)名叫foo的Infra容器（Docker模塊的博文提過(guò)的）來(lái)hold住整個(gè)Pod的Network space
- 如果是基于虛擬化技術(shù)的容器梢为，比如Kata COntainers項(xiàng)目，他的CRI shim就會(huì)直接創(chuàng)建出一個(gè)輕量級(jí)的虛擬機(jī)來(lái)充當(dāng)Pod轰坊，如上圖的vm runtime铸董。
除了上述提到的對(duì)容器生命周期的實(shí)現(xiàn)之外，CRI shim還要做另外一部分十分重要的事情肴沫，就是實(shí)現(xiàn)exec粟害，logs等接口，這部分接口在調(diào)用gRPC期間颤芬，kubelet需要維護(hù)一個(gè)長(zhǎng)連接來(lái)傳輸數(shù)據(jù)悲幅。想exec，logs這類API站蝠，被稱為Streaming API夺艰。CRI shim中對(duì)Streaming API的實(shí)現(xiàn)，依賴于一套獨(dú)立的Streaming Server機(jī)制沉衣。原理示意圖如下：
- 請(qǐng)求先到APi Server
- API Server調(diào)用kubelet的Exec API
- kubelet調(diào)用CRI的Exec接口，CRI shim”響應(yīng)“該接口
- CRI shim并沒(méi)有直接調(diào)用下層容器項(xiàng)目的接口减牺，而是返回Url給kubelet豌习，這個(gè)URL就是CRI shim對(duì)應(yīng)的Streaming Server的地址和端口。
- kubelet拿到這個(gè)URL之后拔疚，以redirect方式返回給API Server
- API server通過(guò)URL發(fā)起真正的/exec請(qǐng)求肥隆，與他建立長(zhǎng)連接
什么是Streaming Server？
