与Kubernetes渐行渐远，Docker未来在哪里？

作者：邹大斌 2020-12-11 09:35:58

云计算 很长时间以来，谈到容器，Kubernetes + Docker好像是标配，现在看来并不一定。

这几天一则Kubernetes将放弃Docker的消息引起业内广泛关注。根据Kubernetes社区给出的说明，在1.20版本之后，Kubernetes将不再支持把Docker作为容器运行时使用，据此不少人开始担心Docker未来不能用了。实际上，这并不是说Kubernetes要完全抛弃Docker，CNCF也提醒说不要惊慌，Docker 生成的镜像将继续在用户的集群中与所有运行时一起工作。但这件事还是让人不免产生联想，Docker还有一个怎样的未来?很长时间以来，谈到容器，Kubernetes + Docker好像是标配，现在看来并不一定。 

[[357045]] 

Kubelet不再支持Docker运行时

人们对Docker未来的担心源于Kubernetes 在1.20版本中 的 ChangeLog 提到，kubelet 中的 Docker 支持功能现已弃用，并将在之后的版本中被删除。社区解释说，这么做的原因是，Kubelet 之前使用的是一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持，但 Kubernetes 社区发现其维护存在问题，因此建议大家考虑使用包含 CRI 完整实现的可用容器运行时。

首先要说明的是，这里提到的Docker运行时并不等同于我们经常说的Docker，这可能是让人们以为Docker被Kubernetes抛弃的一个原因。运行时(Runtime)为应用程序运行时提供保障的一个环境，通常是一些可以重用的程序/库或者实例，这些实例可以在它们运行的时候被连接或者被任何程序调用。在Kubernetes集群内部也有一种称为容器运行时的组件，负责提取并运行容器镜像。Docker就是目前最流行的容器运行时，除此之外容器运行时还有Containerd与CRI-O。

与Containerd与CRI-O的定位就是一个运行时不同，Docker集成了太多功能，而很多功能作为一个运行时并非必须，比如容器创建，而且Docker最初在设计上也并未考虑到被嵌入到Kubernetes这种用法。

应该说，当初为了支持使用Docker的这个运行时，kubelet做出了妥协。如果采用Containerd与CRI-O运行时，其调用流程是：kubelet向CRI-Container插件发出调用请求，由CRI-Container再和容器运行时通信，完成请求的各种操作，但采用Docker运行时，这个流程就需要做出改变。由于Docker运行时并不兼容CRI，不得不引入一个新的插件Dockershimi作为缓冲。此时流程变成：kubelet先向Dockershimi发出请求，由Dockershimi调用Docker运行时，Docker运行时再调用其中的Containerd，由Containerd来负责完成请求的各种操作。可以看出，这个过程中Docker运行时有点尬尴，它的加入不仅在流程上多了一个环节，引入了Dockershimi，而Dockershimi的介入又引发了新的问题，必须额外加以维护，否则就可能引发安全问题。

如今，随着Kubernetes社区的逐渐强大，当初Kubernetes向Docker做出的妥协现在不打算继续了，这才有了kubelet不再支持Docker运行时的举措。目前来看这件事的影响不大，正如CNCF所言，Docker不会就此消亡，Docker会继续构建起不计其数的容器，开发人员仍然可以继续采用Docker，继续将Docker作为开发工具，Docker所生成的镜像仍可在Kubernetes集群内正常运行。

如果使用的是云上的容器服务，比如GKE或者EKS等托管Kubernetes服务，则需要确保在未来的Kubernetes版本彻底去除Docker支持之前，为工作节点引入受支持的容器运行时。如果是自己负责管理的集群，则要注意更新和调整运行时以避免服务中断。在1.20版本中，将收到Docker弃用警告。而在未来的Kubernets版本(计划在2021年下半年发布的1.23版本)中，Docker运行时将被彻底移除、不再受到支持。

然而，长期来看呢?

Docker的未来在哪里?

毋庸置疑，容器的流行Docker功不可没。在Docker出来之前，容器已经存在多年，但并不普及，直到Docker的出现。2013年，Docker的出现第一次把运行容器变得这么简单，使用Docker开发人员可以轻松启动、停止和撤销容器，而且其低学习曲线和易用性使其成为软件开发过程中的主流。

可以说，Docker以一己之力将容器这种相对边缘的技术硬生生地变成了网红。Docker的走红带动了Docker生态，大量围绕着 Docker 项目的网络、存储、监控、CI/CD、甚至 UI 项目纷纷出台，也涌现出了Rancher等一批在开源创业公司。与此同时，竞争的种子也就此埋下。

Docker最初从开发端发力，一家独大，但是要Docker希望继续做大，特别是获取商业价值，就需要向应用部署和运营方向发力，提供部署、监控和管理等放方方面面的工具，Swarm就是其中之一。而对CoreOS、Red Hat、谷歌和微软等这些应用程序运行平台提供方而言，支持容器是刚需，但它们希望通过容器运行时的标准化，来尽可能降低Docker的影响。显然，Docker并不愿意，特别是当时Docker如此火爆的背景之下。这就是双方争夺的焦点。

OCI规范的推出就是双方竞争达成妥协的结果。2015 年 Docker 公司牵头，联合CoreOS、Google、RedHat 等公司共同宣布，Docker 将自己的容器运行时库 Libcontainer 捐出，并改名为 RunC 项目，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范，这就是 OCI( Open Container Initiative )。OCI 的提出目的是将在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来，为其他厂商不依赖于 Docker 项目构建各自的平台提供可能。

OCI对Docker的影响其实不大，特别是相比于同年成立的CNCF(Cloud Native Computing Foundation)，这个由Google、RedHat 等开源基础设施领域玩家们牵头发起的基金会，准备以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

与之间的较量不同，这次的较量已经离开了Docker擅长的开发领域，更多地在应用的部署和运营，也就是PaaS层面展开，这些恰恰是红帽、Google等所擅长的。Kubernetes从最擅长的容器编排入手，把Docker作为其中一个组件，可以说从一开始就站在战略制高点。借助Google 在Borg上积累的先进技术加上Red hat等在开源软件方面运营的经验，很快Kubernetes就在竞争中开始领先。

当然，刚开始时，这种竞争是很温和，2014年Kubernetes诞生时，它使用了Docker，因为Docker是当时最流行的容器运行时。当时，除了Docker + Kubernetes，还可以选择Docker+Mesos、Docker+Swarm。

应该说，Kubernetes与Docker并不是直接的竞争关系，直接竞争的是Docker的Swarm。Swarm是一个集群和调度工具，作用类似于Kubernetes。不过，Swarm与Kubernetes这两者的竞争实质是对容器话语权的竞争，因此，本质上也是Docker与CNCF之间的竞争。

为了对抗Kubernetes，2016 年Docker 公司宣布放弃Swarm 项目，将容器编排和集群管理功能全部内置到 Docker 项目当中。Docker 公司意识到了 Swarm 项目目前唯一的竞争优势，就是跟 Docker 项目的无缝集成。不过，这一招看来不灵，Docker不久就在与CNCF的较量中败下阵来，在2017年10月的DockerCon EU 大会上，Docker官方宣布支持Kubernetes，将在自己的主打产品 Docker 企业版中内置 Kubernetes 项目，这也就是意味着，容器编排领域的争夺已经落幕，Kubernetes得到了认可。

回头看来，失利的Docker开始还能凭借强大的容器开发者生态发挥自己的影响力，这才有了kubelet做出的妥协，专门引入Dockershimi。然而，随着时间的推移，Kubernetes社区的逐渐强大，Kubernetes的生态越来越完善，Docker的话语权逐渐减少，被边缘化也在情理之中，Kubelet撤销对Docker的特殊待遇是迟早要发生的。因此，未来的Docker更大可能是保持在开发领域发挥自己的独特价值。

不过，无论如何，从Docker 2013年正式上市以来，以一己之力带火了容器技术，给软件行业带来了颠覆性变革，推动了软件行业乃至整个IT行业的发展和创新，从这点而言Docker是当之无愧的英雄，即使失败也应该赢得我们的尊重。