容器运行时
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 优秀。