解读“K8S不支持Docker”

容器不只是 Docker ，但不可否认 Docker 是容器的代名词、容器时代的引领者。实际上 K8S 出现并得以快速发展，也是由于 Docker 的强大优势和快速发展， 2014 年 Google 推出 Kubernetes 也主要用于解决大规模场景下 Docker 容器编排的问题。

2015 年，由 Docker 公司和其他容器行业领导者共同成立（它也是 Linux 基金会旗下项目） OCI （ Open Container Initiative ）， OCI 主要包含两个规范：（ 1 ）运行时规范（ runtime-spec ）：容器运行时，如何运行指定的文件系统上的包；（ 2 ）容器镜像规范（ image-spec ）：如何创建一个 OCI 运行时可运行的文件系统上的包。 Docker 把它自己的容器镜像格式和 runtime ( 现在的 runc ) 都捐给了 OCI 作为初始工作。 2016 年 6 月， Docker v1.12 发布，推出 Docker 多主机多容器编排解决方案，即 Docker Swarm ，意在完善其容器生态圈技术框架，并且尝试撼动 K8S 在容器编排的地位。

2016 年 12 月， Kubernetes 未解决不同容器运行时产品 / 项目的兼容性问题时（此时 K8S 已在尝试支持其他容器运行时，如 rkt 、 cri-o 、 containerd 等 ），发布统一标准的 CRI （ Container Runtime Interface ），凡是支持 CRI 的运行时，皆可直接作为 Kubernetes 的底层运行时。为了将自己运行时产品或项目运行在 K8S 下，有些 runtime 厂商或社区就开发了 符合 CRI 标准的转接线就是一个 shim ，叫做 CRI-shim 。但对 Docker 而言，其自身在容器方面过于强大且自信，为提供符合 K8S 的 CRI 接口规范的 shim ，不过考虑到 Docker 的用户群体庞大， K8S （其实是 kubelet ）里继续内置了连接 docker 的代码叫做（ dockershim ）。

所谓 K8S 不在支持 Docker ，实质上是 K8S 要放弃对现在 K8S 代码仓库中的 dockershim 的维护支持， 以便其可以像计划的那样，仅负责维护其 CRI ，任何兼容 CRI 的运行时，皆可作为 K8S 的 runtime 。实际上，在 K8S 提出 CRI 时， Docker 在技术方面是可以实现的，但这也会带来一个新的问题，即使 Docker 实现了 CRI ，但它仍然不是一个单纯的容器运行时，它本身包含了大量的非 “ 纯底层容器运行时 ” 所具备的功能。所以后来 Docker 分离出来 containerd 项目，作为一个底层容器运行时出现了，它是 K8S 容器运行时更好的选择。目前， Docker 使用 containerd 作为其底层容器运行时以及众多的云厂商及公司在生产环境中使用 containerd 作为其 K8S 的运行时，这也从侧面验证了 containerd 的稳定性。现在 K8S 和 Docker 社区都相信 containerd 已经足够成熟可直接作为 K8S 的运行时了，而无需再通过 dockershim 使用 Docker 作为 K8S 的运行时了。这也标志着 Docker 为 K8S 提供一个现代化的容器运行时的承诺最终兑现了。同时， K8S 代码仓库中的 dockershim 将会在未来版本中移除，但是 Mirantis 公司（ 2019 年 Mirantis 收购 Docker 的企业服务）已经和 Docker 达成合作，在未来会共同维护一份 dockershim 组件，以便支持 Docker 作为 K8S 的容器运行时。

综上， Kubernetes 放弃对 dockershim 的维护，对于用户以及 K8S 开发工程师而言，实质上并未有影响；对于容器集群管理员，则需要考虑是否要在未来版本中，将容器运行时，升级为支持 CRI 的运行时，比如 containerd 。 当然，如果你并不想切换容器运行时，那也没关系， Mirantis 公司未来会和 Docker 共同维护 dockershim , 并作为一个开源组件提供。