容器运行时说明与比较

容器运行时

Container Runtime 是运行于 k8s 集群每个节点中，负责容器的整个生命周期。Docker 就目前来说是应用最为广泛的。随着容器云的发展，涌现了很多容器运行时。Google 为了将 kubelet 和特定的容器运行时解耦（主要还是为了干掉 Docker），于是推出了 CRI（容器运行时接口）。

容器运行时接口

CRI 是 k8s 定义的一组 gRPC 服务。kubelet 作为客户端，基于 gRPC 框架，通过 Socket 和容器运行时通信。CRI 包括两类服务：镜像服务（Image Service）和运行时服务（Runtime Service）。镜像服务提供下载、检查和删除镜像的远程程序调用。运行时服务用于管理容器的生命周期，以及和容器交互的调用（exec / attach / port-forward）。

容器运行时层级

Container Runtime 分为高低两个层级。

高层级运行时

Dockershim、containerd 和 CRI-O 都是遵循 CRI 的容器运行时，属于高层级运行时，主要是面向外部提供 gRPC 调用。

注意这里是 Dockershim，并不是 Docker，Docker 至今也没有遵循 CRI。

OCI

OCI（OPen Container Initiative）定义了创建容器的格式和运行时的开源行业标准，包括镜像规范和运行时规范。

高层级运行时会下载一个 OCI 镜像，并把它解压成 OCI 运行时文件系统包（filesystem bundle）。

低层级运行时

低层级运行时定义如何为新容器设置 Linux namespaces 和 cgroups，以及 rootfs 等操作， runC 就是具体的参考实现。除了 runC 外，还有很多其他的运行时遵循 OCI 标准，例如 kata 以及 gVisor。

容器运行时比较

Docker 的多层封装和调用，导致其在可维护性上略逊一筹。containerd 和 CRI-O 的方案比 Docker 简洁很多。

dockershim 遵循 CRI，并把请求转为 dockerd 可处理的请求，其代码集成在 kubelet 中，这也是 k8s 急于摆脱 Docker 的原因之一。

真正的启动容器是通过 containerd-shim 去调用 runC 来启动容器的，runC 启动完成后会直接退出，containerd-shim 会成为容器进程的父进程，负责收集容器进程的状态，上报给 containerd，并在容器中 pid 为 1 的进程退出后接管容器中的子进程，确保不会出现僵尸进程。同时也避免了宿主机上 containerd 进程挂掉的话，所有容器进程都退出。

containerd 和 Docker 细节差异

Docker 作为容器运行时，k8s 其实根本没有使用 docker 本身的存储、网络等功能，只是用了 Docker 的 Image 功能，来满足 CRI 中的镜像服务。

containerd 和 CRI-O

CRI-O是由红帽发起并开源的一款容器运行时，本身比较新，没有太多的生产实践。而且在社区的测试结果中，在操作容器方面的性能以及延时都没有 containerd 优秀。