简介
《深入剖析Kubernetes》：kubelet 调用下层容器运行时的执行过程，并不会直接调用Docker 的 API，而是通过一组叫作 CRI（Container Runtime Interface，容器运行时接口）的 gRPC 接口来间接执行的。Kubernetes 项目之所以要在 kubelet 中引入这样一层单独的抽象，当然是为了对 Kubernetes 屏蔽下层容器运行时的差异。
理解容器运行时接口CRI有一句话说得很好，「软件问题都可以通过加一层来解决」，我们的 CRI 就是加了这样一层。
kubelet 与 CRI
目前 dockershim 还是存在于 Kubelet 的代码中的，它是当前性能最稳定的一个容器运行时的实现。除了 dockershim 之外，其他容器运行时的 CRI shim，都是需要额外部署在宿主机上的。
CRI 接口
CRI 标准的制定是自上而下的，通过 Kubernetes 的一些 feature 反向地要求 CRI 提供这样的功能，进而完善 CRI 规范。
CRI实现了两个GRPC协议的API，提供两种服务ImageService和RuntimeService。
// grpcServices are all the grpc services provided by cri containerd.
type grpcServices interface {
runtime.RuntimeServiceServer
runtime.ImageServiceServer
}
// CRIService is the interface implement CRI remote service server.
type CRIService interface {
Run() error
// io.Closer is used by containerd to gracefully stop cri service.
io.Closer
plugin.Service
grpcServices
}
CRI的实现CRIService中包含了很多重要的组件：其中最重要的是cni.CNI，用于配置容器网络。还有containerd.Client，用于连接containerd来创建容器。
// criService implements CRIService.
type criService struct {
// config contains all configurations.
config criconfig.Config
// imageFSPath is the path to image filesystem.
imageFSPath string
// os is an interface for all required os operations.
os osinterface.OS
// sandboxStore stores all resources associated with sandboxes.
sandboxStore *sandboxstore.Store
// sandboxNameIndex stores all sandbox names and make sure each name
// is unique.
sandboxNameIndex *registrar.Registrar
// containerStore stores all resources associated with containers.
containerStore *containerstore.Store
// containerNameIndex stores all container names and make sure each
// name is unique.
containerNameIndex *registrar.Registrar
// imageStore stores all resources associated with images.
imageStore *imagestore.Store
// snapshotStore stores information of all snapshots.
snapshotStore *snapshotstore.Store
// netPlugin is used to setup and teardown network when run/stop pod sandbox.
netPlugin cni.CNI
// client is an instance of the containerd client
client *containerd.Client
......
}
我们知道 Kubernetes 的一个运作的机制是面向终态的，在每一次调协的循环中，Kubelet 会向 apiserver 获取调度到本 Node 的 Pod 的数据，再做一个面向终态的处理，以达到我们预期的状态。循环的第一步，首先通过 List 接口拿到容器的状态，再通过 Sandbox 和 Container 接口来创建容器，另外还有镜像接口用来拉取容器镜像。
需要注意的是，我们的 CNI（容器网络接口）也是在 CRI 进行操作的，因为我们在创建 Pod 的时候需要同时创建网络资源然后注入到 Pod 中（PS：CNI包含在创建Pod 这个动作里）。接下来就是我们的容器和镜像。我们通过具体的容器创建引擎来创建一个具体的容器。
CRI streaming 接口
它可以用来在容器内部执行一个命令，又或者说可以 attach 到容器的 IO 流中做各种交互式的命令。
首先 exec 操作会发送到 apiserver，经过鉴权，apiserver 将对 Kubelet Server 发起 exec 的请求，然后 Kubelet 会调用 CRI 的 exec 接口将具体的请求发至容器的运行时。这个时候，容器运行时不是直接地在 exec 接口上来服务这次请求，而是通过我们的 streaming server 来异步地返回每一次执行的结果。也就是说 apiserver 其实实际上是跟 streaming server 交互来获取我们的流式数据的。这样一来让我们的整个 CRI Server 接口更轻量、更可靠。
CRI 相关工具
crictl是一个类似 docker 的命令行工具，用来操作 CRI 接口。它能够帮助用户和开发者调试容器问题，而不是通过 apply 一个 yaml 到 apiserver、再通过 Kubelet 操作的方式来调试。这样的链路太长，而这个命令行工具可以直接操作 CRI。