k8s-容器运行时接口CRI

　　在 CRI 出现之前（也就是 Kubernetes v1.5 之前），Docker 作为第一个容器运行时，Kubelet 通过内嵌的 dockershim 操作 Docker API 来操作容器，进而达到一个面向终态的效果。

　　越来越多的容器运行时被开发，促进了CRI的出现。

　　对容器运行时的操作抽象出一个接口，将 Kubelet 代码与具体的容器运行时的实现代码解耦开，只要实现了这样一套接口，就能接入到 Kubernetes 的体系中。

　　有一句话说得很好，「软件问题都可以通过加一层来解决」，我们的 CRI 就是加了这样一层。CRI 接口的通信协议是 gRPC。

CRI实现

CRI 接口主要包含两个部分：

 　　一个是 CRI Server，即通用的比如说创建、删除容器这样的接口；

　　另外一个是流式数据的接口 Streaming Server，比如 exec、port-forward 这些流式数据的接口。

通过 CRI 操作容器的生命周期

Kubernetes 的一个运作的机制是面向终态的，在每一次调协的循环中，Kubelet 会向 apiserver 获取调度到本 Node 的 Pod 的数据，再做一个面向终态的处理，以达到预期的状态。

Kubelet 就会通过 CRI 执行以下操作：

　　首先调用 RunPodSandbox 接口来创建一个 Pod 容器，Pod 容器是用来持有容器的相关资源的，比如说网络空间、PID空间、进程空间等资源；

　　然后调用 CreatContainer 接口在 Pod 容器的空间创建业务容器；

　　再调用 StartContainer 接口启动容器，相对应的销毁容器的接口为 StopContainer 与 RemoveContainer。

CRI streaming 接口

流式接口 exec：exec 操作会发送到 apiserver，经过鉴权，apiserver 将对 Kubelet Server 发起 exec 的请求，然后 Kubelet 会调用 CRI 的 exec 接口将具体的请求发至容器的运行时。这个时候，容器运行时不是直接地在 exec 接口上来服务这次请求，而是通过 streaming server 来异步地返回每一次执行的结果。也就是说 apiserver 其实实际上是跟 streaming server 交互来获取我们的流式数据的。这样一来让我们的整个 CRI Server 接口更轻量、更可靠。