46 | 解读 CRI 与 容器运行时

kubelet 可以直接对接contained ? 中间不需要额外实现cri shim ？还是containerd 中已经集成了cri shim？

DevicePlugin中的allocate函数是是在container creating的时候被调用，从而device plugin可以执行特定的操作，比如attach设备以及驱动目录。 所以应该是使用到了： Createcontainer()这个接口

containerd应该会把请求交给contained-shim，然后再调runC吧

调度器将Pod调度到某一个Node上后，Node上的Kubelet就需要负责将这个Pod拉起来。在Kuberentes社区中，Kubelet以及CRI相关的内容，都属于SIG-Node。 Kubelet也是通过控制循环来完成各种工作的。kubelet调用下层容器运行时通过一组叫作CRI的gRPC接口来间接执行的。通过CRI， kubelet与具体的容器运行时解耦。在目前的kubelet实现里，内置了dockershim这个CRI的实现，但这部分实现未来肯定会被kubelet移除。未来更普遍的方案是在宿主机上安装负责响应的CRI组件（CRI shim），kubelet负责调用CRI shim，CRI shim把具体的请求“翻译”成对后端容器项目的请求或者操作 。 不同的CRI shim有不同的容器实现方式，例如：创建了一个名叫foo的、包括了A、B两个容器的Pod Docker: 创建出一个名叫foo的Infra容器来hold住整个pod，接着启动A，B两个Docker容器。所以最后，宿主机上会出现三个Docker容器组成这一个Pod Kata container: 创建出一个轻量级的虚拟机来hold住整个pod，接着创建A、B容器对应的 Mount Namespace。所以，最后在宿主机上，只会有一个叫做foo的轻量级虚拟机在运行

docker shim 是不是可以理解成remote+CRI shim的一个k8s内部集成的一种实现

天冷适合搞学习 打卡

对CRI的认识更进一层了

Containerd 中的cri-shim和用来控制runC的containerd-shim有什么区别呢？

老师请教两个问题: 1. 为什么kubelet要给apiserver返回redirect url呢? 这样做有什么特殊考虑吗? 2. 镜像服务, 以及下载完镜像之后, 如何和createcontainer接口发生关联的, 这块的细节能讲讲吗?

第四十四课:解读CRI与容器运行时 CRI机制能够发挥作用的核心，就在于每个容器项目现在都能自己实现一个CRI shim，自行对CRI请求进行处理。 CRI可以分为两组，第一组是RuntimeService。它提供的接口主要是跟容器相关的操作，比如创建或启动容器，删除容器，和执行exec命令等。这组的设计原则是确保这个接口本身只关注容器。第二组是ImageService，它提供的接口主要是容器镜像相关的操作，比如拉取和删除镜像等。