Kubernetes 理解笔记之容器运行时接口CRI

---

本文进入到 kubelet 调用下层容器运行时的执行过程，着重分析 CRI 这一接口设计的思想与工作原理。【Kevin亓】

---

CRI 设计思想

kubelet 调用下层容器运行时的执行过程，并不会直接调用 Docker 的 API，而是通过一组叫作 CRI（Container Runtime Interface，容器运行时接口）的 gRPC 接口来间接执行的。

Kubernetes 项目之所以要在 kubelet 中引入这样一层单独的抽象，当然是为了对 Kubernetes 屏蔽下层容器运行时的差异。

每台宿主机上一般单独安装一个负责响应 CRI 的组件，这个组件一般被称作 CRI shim。具体工作就是扮演 kubelet 与容器项目之间的“垫片”（shim）。所以它的作用非常单一，那就是实现 CRI 规定的每个接口，然后把具体的 CRI 请求“翻译”成对后端容器项目的请求或者操作。

kubelet 、容器运行时（如 Docker）以及 CRI ：

由图看创建 Pod 大致流程：

1. master 上调度：当 Kubernetes 通过编排能力创建了一个 Pod 之后，调度器会为这个 Pod 选择一个具体的节点来运行。
2. kubelet 创建 CRI 请求：kubelet 就会通过自身的 SyncLoop 来判断需要执行的具体操作，比如创建一个 Pod。那么此时，kubelet 实际上就会调用一个叫作 GenericRuntime 的通用组件来发起创建 Pod 的 CRI 请求。
3. 容器运行时响应CRI请求并执行具体