1 CRI
CRI(container runtime interface)看名字还以为是容器层面的运行时接口, 但 是实际上是k8s定义的容器运行时相关操作, 包含"创建SandBox容器"等 k8s相关的接口定义, 并不是容器层面的东西. CRI可以理解成golang中的一个 interface, 定义了接口, 后端拥有多种不同的实现, 包括containerd, cri-o等.
CRI定义的接口:
https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto
早期kubelet在代码中理解不同的运行时, 后面觉得这样耦合在kubelet来不便于 迭代, 因此将相关操作专门抽出来做成一个api集合, kubelet代码中需要启动/ 暂停容器等操作时, 通过远程调用的方式将请求发送到一个RemoteSerivce来完 成, 这样就将容器运行时从kubelet中解耦了. kubelet的启动参数中有一项是 ContainerRuntimeEndpoint用于指定CRI的具体实现的server端地址
2 CRI vs OCI(Open Container Initiative)
CRI是k8s定义的用于kubelet与运行时交互的接口标准, OCI则是容器层面的接口 标准和镜像标准
实现
CRI常见的实现有cri-o, containerd等 OCI的常见实现则有runc, runv, gvisor等
其中, cri-o衔接了OCI和CRI, 可以理解成将OCI封装了一下实现了CRI定义的接 口, 底层调用OCI标准的接口, 这样可以复用不同的OCI实现, 因此基于cri-o, 可以使得k8s的容器允许时使用runc/runv.
containerd则是与runc强绑定. runc仅提供基础的容器操作, containerd在runc 的基础之上增加了一些产品化的功能, 例如镜像传输.
runc/runv, gvisor主要是容器和虚拟机的差异