在上一篇文章中我也提到了,CRI 机制能够发挥作用的核心,就在于每一种容器项目现在都
可以自己实现一个 CRI shim,自行对 CRI 请求进行处理。这样,Kubernetes 就有了一个
统一的容器抽象层,使得下层容器运行时可以自由地对接进入 Kubernetes 当中。
所以说,这里的 CRI shim,就是容器项目的维护者们自由发挥的“场地”了。而除了
dockershim 之外,其他容器运行时的 CRI shim,都是需要额外部署在宿主机上的。
举个例子。CNCF 里的 containerd 项目,就可以提供一个典型的 CRI shim 的能力,即:
将 Kubernetes 发出的 CRI 请求,转换成对 containerd 的调用,然后创建出 runC 容器。
而 runC 项目,才是负责执行我们前面讲解过的设置容器 Namespace、Cgroups 和
chroot 等基础操作的组件。所以,这几层的组合关系,可以用如下所示的示意图来描述。
文档被以下合辑收录
评论