K8s决定在 1.20 开始放弃 Docker,并在1.21完全抛弃 Docker 的支持。
2020 年 12 月,Kubernetes 社区决定着手移除仓库中 Dockershim 相关代码,对于k8s和 Docker 两个社区来说都意义重大。
如上图所示,Kubernetes节点代理 Kubelet为了访问Docker提供的服务需要先经过社区维护的 Dockershim,Dockershim 会将请求转发给管理容器的 Docker 服务。
Kubernetes 通过下面的一系列接口为不同模块提供扩展性:
Kubernetes 在较早期的版本中就引入了 CRD、CNI、CRI 和 CSI 等接口,只有用于扩展调度器的调度框架是 Kubernetes 中比较新的特性。
Kubernetes 早在 1.3 就在代码仓库中同时支持了 rkt 和 Docker 两种运行时。
但这些代码为 Kubelet 组件的维护带来了很大的困难,不仅需要维护不同的运行时,接入新的运行时也很困难。
容器运行时接口(Container Runtime Interface、CRI)是 Kubernetes 在 1.5 中引入的新接口,Kubelet 可以通过这个新接口使用各种各样的容器运行时。
其实 CRI 的发布就意味着 Kubernetes 一定会将 Dockershim 的代码从仓库中移除。
CRI 是一系列用于管理容器运行时和镜像的 gRPC 接口,我们能在它的定义中找到 RuntimeService 和 ImageService 两个服务。
与容器运行时相比,Docker 更像是一个复杂的开发者工具,它提供了从构建到运行的全套功能。
开发者可以很快地上手 Docker 并在本地运行并管理一些 Docker 容器,然而在集群中运行的容器运行时往往不需要这么复杂的功能,Kubernetes 需要的只是 CRI 中定义的那些接口。
虽然 Docker 中包含 CRI 需要的所有功能,但是都需要实现一层包装以兼容 CRI。
社区提出的很多新功能都没有办法在 Dockershim 中实现,例如 cgroups v2 以及用户命名空间。
Kubernetes 作为比较松散的开源社区,每个成员尤其是各个 SIG 的成员都只会在开源社区上花费有限的时间。
而维护 Kubelet 的 sig-node 又尤其繁忙,很多新的功能都因为维护者没有足够的精力而被搁置。
既然 Docker 社区看起来没有打算支持 Kubernetes 的 CRI 接口,维护 Dockershim 又需要花费很多精力,就能理解为什么 Kubernetes 会移除 Dockershim 了。
Kubelet 之前使用一个名为 dockershim 的模块,用以实现对 Docker 的 CRI 支持。但 Kubernetes 社区发现了与之相关的维护问题,建议大家考虑使用包含 CRI 完整实现(兼容 v1alpha1 或 v1)的可用容器运行时。
Docker 并不支持 CRI(容器运行时接口)这一 Kubernetes 运行时 API,而 Kubernetes 用户一直以来所使用的其实是名为“dockershim”的桥接服务。Dockershim 能够转换 Docker API 与 CRI。
Docker 本身也是一款非常强大的工具,可用于创建开发环境。为了解造成当前状况的原因,需要全面分析 Docker 在现有 Kubernetes 架构中的作用。
Docker公司把containerd和runc拆出来变成了开源项目,docker的底层是containerd+runc .