CRI
kubelet在启动容器进程的时候，要真正的启动这些容器进程，随着版本的迭代，它逐渐将启动过程当中这些标准的行为，抽象为一个一个的接口。
它的好处是kubelet就不需要和具体的runtime产生绑定关系了，kubelet自己是一些代码框架，它定义好这些接口，它只需要调用这些接口，由不同的容器运行时提供商来实现这些接口。（让运行时可以适配我的标准，这样可以使用你也可以不使用你）
这样我们就可以选择是使用docker还是containerd呢还是kata其他类型的容器？
这样就使得kubernetes就不和某一个运行时有具体的强绑定关系，防止被某个厂商锁死。
容器运行时（Container Runtime），运行于Kubernetes（K8s）集群的每个节点中，负责容器的整个生命周期。其中Docker是目前应用最广的。随着容器云的发展，越来越多的容器运行时涌现。为了解决这些容器运行时和Kubernetes的集成问题，在Kubernetes1.5版本中，社区推出了CRI（Container Runtime Interface，容器运行时接口）以支持更多的容器运行时。
CRI就是，它将容器运行时的这些实现标准的接口都抽象出来了，你们kubelet要去操作任何的容器进程都是通过CRI的接口，然后不同的容器运行时会实现这些CRI接口，最终去操作这些容器进程。
CRI是Kubernetes定义的一组gRPC服务。kubelet作为客户端，基于gRPC框架，通过Socket和容器运行时通信。
它包括两类服务∶镜像服务（Image Service）和运行时服务（Runtime Service）。
- 镜像服务提供下载、检查和删除镜像的远程程序调用。
- 运行时服务包含用于管理容器生命周期，以及与容器交互的调用（exec/attach/port-forward）的远程程序调用。
kubelet是客户端，可以看到在kubelet里面有grpc client，它会去基于grpc框架去调用运行时服务，类似docker containerd这类的服务。它是运行在kubelet之外的，在安装kubernetes的时候，会先去安装docker containerd，安装完之后再去安装kubelet。
这样的话kubelet作为客户端来调用runtime的接口。这些runtime就要按照CRI的规范去实现那些接口。
容器运行时最终的目的是要去启动一个一个的容器进程，所以你可以理解为容器运行时它本身是一个中间层，它向上面对的是kubelet，向下面对的是这些容器进程。
所以它分为high-level-runtime和low-level-runtime，high-level-runtime是对外提供的这些grpc服务。由客户端grpc client来调用这些服务，它接受到这些请求需要通过low-level的api去启动和操作这些容器。
它有点像一层代理，它只是做命令的转发，接受来自客户端的请求，然后再去操作下面的容器进程。
它所谓的low-level-runtime，容器的话就是runc。
运行时的层级
Dockershim， containerd和CRI-O都是遵循CRI的容器运行时， 我们称他们为高层级运行时(High-level Runtime)。
容器运行时最终遵循了oci的一个标准，oci定义了容器相关的行业标准。这个行业标准主要分为了三大类，定义了镜像如何打包，如何解压的这样一个规范。通过镜像如何去运行容器进程这样的一个规范。
OCI（Open Container Initiative，开放容器计划）定义了创建容器的格式和运行时的开源行业标准，包括镜像规范（Image Specification）和运行时规范（Runtime Specification）。
镜像规范定义了OCI镜像的标准。高层级运行时将会下载一个OCI镜像，并把它解压成 OCI运行时文件系统包（filesystem bundle）（还有存储镜像文件到指定的目录下）。
运行时规范则描述了如何从OCI运行时文件系统包运行容器程序，并且定义它的配置、运行环境和生命周期。如何为新容器设置命名空间（namepsaces）和控制组（cgroups），以及挂载根文件系统等等操作，都是在这里定义的。它的一个参考实现是runC。我们称其为低层级运行时（Low-level R untime）。除runC以外，也有很多其他的运行时遵循OCI标准，例如kata-runtime。
CRI
containerd是能够取代docker的，因为docker本身内嵌了containerd的，docker是一个独立的产品，我们可以通过docker的命令去管理自己的网络，管理自己的存储，所以docker大部分臃肿的逻辑都在docker daemon它自身的逻辑上面，这些逻辑处理完之后也是将请求发给自带内嵌的containerd里面去， 这样其实真正执行的逻辑是在containerd里面。
存储，网络是kubernetes和docker之间的竞争，在kubernetes里面用的都是kubernetes管理的这套体系，那么docker的那部分其实是冗余的。不再使用docker自身的daemon了，但是可以用你docker自身所带的containerd的。
对于CRI来说主要的就是runtimeservice和imageservice。
imageservice提供了很多接口，主要是对image相关的操作。
runtimeservice同样通过了很多接口，可以看到对sandbox有很多操作，以及和对用户容器相关的。
开源运行时比较
上面是三个常用的运行时，最上面的路径其实是最长的。
如果是docker运行时，那么是kubelet调用dockeshim，调用docker再去调用containerd，containerd再通过runc的接口去调用底层的容器进程。
如果是containerd那么就没有docker-shim和docker，直接由kubelet发起命令到containerd，然后containerd到runc。
如果是crio那么更加轻量级，kubelet调用crio，然后直接调用runc。
越来越简洁。
Docker和Containerd的细节差异
如果是通过kubelet去调用docker的话，这个请求是在kubelet的cri接口调用docker-shim，docker-shim再连接到docker-daemon，docker-daemon里面红圈的这部分才是有用的，也就是和image相关的操作，以及正真去去调用containerd的这部分操作是有用的，上面存储网络，已经docker提供的cli这些都是不需要的，那么这些都是冗余的。
如果将docker换掉的话，那么红线外的部分就没有了，那么复杂性就大大降低的，直接使用cri的接口调用containerd，移除了这些不必要的调用转发环节，这样整个系统架构更加简单。
上面就是理解去掉docker的意义，这是一个必要的动作。
多种运行时性能比较
在选型的时候一个是架构的简单程度，稳定性，还有它的性能。
