Kubernetes 源碼分析之 kubelet(四)
k8s 版本?v1.18.3?
CRI
CRI 是 Kubernetes 為了將容器運行時抽離出來而定義的接口。一開始 Kubernetes 是不支持 CRI 的，而是抽象了 dockershim，直接對接了 docker。然而隨著容器運行時的增加(主要是當時的 rkt)，頻繁修改 Kubernetes 主線代碼過于麻煩，因此抽象了 CRI 去對接所有的容器運行時。
kubelet 通過 gRPC 和實現(xiàn)了 CRI 的進程交互，以達到解耦合的目的。
CRI 中的 gRPC 服務(wù)定義了以下幾個 interface
(一) RuntimeService，容器運行時相關(guān)的操作
RuntimeVersioner，獲取版本相關(guān)信息
ContainerManager，定義了各種 container 相關(guān)操作
PodSandboxManager，定義了各種 pod 相關(guān)的操作
ContainerStatsManager，定義了 container 的 cpu，memory 之類的 stats
(二)?ImageManagerService，容器鏡像相關(guān)的操作
CRI 的具體定義可以查看?staging/src/k8s.io/cri-api/pkg/apis?下的代碼。
dockershim
dockershim 是 Kubernetes 內(nèi)置的 CRI 實現(xiàn)，用于隔離和 docker 相關(guān)的操作，dockershim 的代碼定義在?pkg/kubelet/dockershim?下。
Kubernetes 1.20 版本后，dockershim 將會被廢棄。
cri-o
cri-o 是一個實現(xiàn)了 CRI 接口的項目，用于和符合 OCI 標準的容器運行時對接。
整個 cri-o 由以下幾個部分組成
OCI compatible runtime
containers/storage
containers/image
networking (CNI)
container monitoring (conmon)
security is provided by several core Linux capabilities
OCI(Open Container Initiative) 是開放容器標準，定義了容器相關(guān)的一系列標準
runtime-spec
image-spec
distribution-spec
OCI runtime spec 中定義了一些容器相關(guān)的操作
1. state
2. create
3. start
4. kill
5. delete
同時還有一些容器相關(guān)的 hooks
prestart
createRuntime
createContainer
startContainer
poststart
poststop
整個容器的生命周期如下
create 命令被調(diào)用
容器的運行時環(huán)境將根據(jù)?config.json?被創(chuàng)建，此時用戶進程未運行
prestart hook 被調(diào)用，如果 hook 失敗了，停止容器，跳轉(zhuǎn)到第 12 步
createRuntime hook 被調(diào)用，如果 hook 失敗了，停止容器，跳轉(zhuǎn)到第 12 步
createContainer hook 被調(diào)用，如果 hook 失敗了，停止容器，跳轉(zhuǎn)到第 12 步
start 命令被調(diào)用
startContainer hook 被調(diào)用，如果 hook 失敗了，停止容器，跳轉(zhuǎn)到第 12 步
runtime 運行用戶進程
poststart hook 被調(diào)用，如果 hook 失敗了，打 warning 日志，繼續(xù)運行
進程退出
delete 命令被調(diào)用
容器被銷毀
poststop hook 被調(diào)用，如果 hook 失敗了，打 warning 日志，繼續(xù)運行
一系列項目
runc?是 OCI runtime 的默認實現(xiàn)
containerd 是 docker 剝離出來的容器相關(guān)的 runtime 實現(xiàn)，containerd 也使用了 runc 作為 OCI runtime。本來 containerd 有個 CRI 實現(xiàn) containerd/cri，不過在 2020.10 月已經(jīng)被合入 containerd 主 repo 了
cri-o?實現(xiàn)了 CRI 并且能夠以符合 OCI 標準 的 runtime 作為底層實現(xiàn)，是 CRI 和 OCI 的中間層
crun?另一個用 C 寫的 OCI runtime，之所以有這樣一個項目是因為 runc 有些比較 hack 的操作(會調(diào)用自己)，然后還直接調(diào)用了 C 代碼
最后
為什么需要定時觸發(fā)?
syncCh為什么需要?
housekeepingcontainerManager 以及 pod 的 cgroups 結(jié)構(gòu)
volumeManager 以及 CSI
CNI
敬請期待 Kubernetes?源碼分析之 kubelet(五)
?點擊屏末?|?閱讀原文?|?即刻學習