解读“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 月， 未解决不同容器运行时产品/项目的兼容性问题时（此时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 , 并作为一个开源组件提供。