Docker的第二次死亡

作者 田晓旭，Tina

左耳朵耗子说过一段话，让人深以为然：

12月2日，Kubernetes发布了一则消息，表示将在即将发布的Kubernetes 1.20版本中弃用Docker支持。CNCF大使Ian Coldwater特地发了一条Twitter消息，呼吁大家对此进行关注：“ Kubernetes中已弃用了Docker支持。你需要注意这一点并做一些计划。这将破坏你的集群。”

这些举动，在技术圈子里引起的震荡就好比又宣布了一次Docker的死亡（第一次是“Swarm的没落”）。虽然这只是一盘大棋中最无关紧要的最后一小步，目的就是让Kubernetes“不再依赖”Docker。

容器技术圈子在短短几年发生了一些重大的变数。

Docker以提供镜像打包的创新技术实现了“一次构建、处处运行”的软件交付方式，开启了一个全新的容器时代。面对平台化的竞争，Docker推出了调度引擎Swarm，但Swarm从未真正流行起来，因为整个行业更倾向于采用Kubernetes，这是Docker第一次死亡：它失去了平台之战。2016年9月，Google和Red Hat联合宣布了“fork Docker”，也就是后来的CRI-O项目，这就是这次弃用事件的起始，同时也宣告了竞争的结束。

谁会受到影响？

Docker源于Linux Container，可以将一台机器的资源分成N份容器，做到资源的隔离，并将可运行的程序定义为标准的docker image。相对来说，Kubernetes属于Docker容器引擎的上层：编排调度层，它可以把不同机器的每份容器进行编排、调度，组成分布式系统。

近几年，Kubernetes已经成为自有机房、云上广泛使用的容器编排方案，最广泛的使用方式是Kubernetes+Docker。运维工程师一方面用Kubernetes中的kubctl命令、k8s API来操作集群，一方面在单机用docker命令来管理镜像、运行镜像。技术专家杨明越给Info Q总结道：“单独用Kubernetes，下层不是Docker的情况，并不算很多”。

“弃用Docker”，具体来说，是Kubernetes将在1.20版本中弃用dockershim。它是一个桥接服务，帮助Kubernetes与Docker通信时屏蔽下层容器运行时之间的差异。

这种桥接服务带来便利性的同时也带来了复杂性。留着时间的流逝，这种复杂性不断“膨胀”，维护Dockershim已成为运维/开发人员的沉重负担。在下一版中，去掉Dockershim将是一个极大的简化，并且恢复了调用的一致性。

尽管Kubernetes在发布消息的时候，表示开发人员对这种转变“不必恐慌”，“Docker还没有死，它仍然有其用途”。但显然Kubernetes的解释并不能令人满意：“是否有人质疑为什么不选择一种更顺畅的迁移方式，而不是像谷歌那样抨击Docker，劝人们赶紧迁移，越快越好”。也有更多开发人员表达了他们并不明白接下来他们需要做些什么。

在生产环境中，企业大量的使用的是经典Kubernetes+ Docker方案，同时在一些公司的场景中也有单独使用Docker的情况。

如果用户的业务部署比较简单，规模也较小，仅仅是为了使用容器做应用交付的便利，也没有其他的功能需求的话，仅仅通过docker run/docker-compose这种方式也能管得好的话，实际上是没必要非得引入Kubernetes这样非常重的编排组件的。反而直接仅仅使用Docker会更轻量，也更好运维。比如to B的软件交付的情况，如果要部署的软件的部署架构比较简单的话，仅仅涉及少量几台机器，服务进程也不多的情况下，也有不少是直接使用Docker，而不引入Kubernetes的，比较轻量、简单。

还有一个就是，使用kubernetes做编排引擎的情况下，实际开发者在日常的开发中，也会比较多地使用Docker。

“对于一般的应用开发者来说，他们一般不会直接去面对Kubernetes的，因此，对于他们来说，可能压根就是无感知的，应用开发者甚至都不用知道他们的业务是用容器运行的。对于整个基于Kubernetes生态的各个解决方案提供商来说，由于当前基于Kubernetes的编排是事实标准，容器的镜像格式又是都遵守OCI的，因此可以说所有的之前的交付的构件，无论容器运行时怎样变化，实际上都不会有啥影响。”网易轻舟容器平台NCS负责人王新勇在接受Info Q的采访中表示，“但对于容器平台提供商来说，可能需要一些适配和准备动作。”

根据Sysdig发布的2019年容器使用报告显示，Docker占据了容器平台市场的大部分份额，占比为79%，而排在第二位的是containerd，占比为18%，排在第三位的CRI-O项目，占比为4%。

CRI-O是Kubernetes的轻量级运行时，希望绕过现有Docker容器的大部分机制直接操作Linux容器，由Red Hat主导，并且也是目前Kubernetes推崇的方式。

“网易已经有比较好的准备，实际上Kubernetes弃用Docker从很早就开始讨论了。很早我们就开始关注和使用Containerd作为我们的容器运行时的一个选项了。后续我们会提供相关的运行时多个选项，并逐步过渡到使用Containerd作为运行时。”王新勇表示。

“我们还可以通过将Dockershim从Kubernetes中抠出来，独立运行，作为Ku-bernetes的cri到Docker API的适配器，实现Kubernetes继续支持Docker，从而保持之前的使用习惯。”

杨明越也认为由于老技术实现的惯性，在生产环境大量使用的经典Kubernetes+ Docker方案依然运行，且运维已经成熟，不会很快升级。对于开发人员、企业，对于K8S API的使用频率、变数，远远大于Docker API，至于Kubernetes和Docker的桥接，更不用关心。因此，即便“彻底弃用Docker”，对开发者与企业的影响也非常有限。

Docker会消亡吗？

Docker和Kubernetes的往事已经非常久远，从亲密伙伴到反目成仇，令人不胜唏嘘。

2013年，当时名叫dot Cloud的Docker公司，开源出来了自己的容器项目Docker。Docker通过镜像打包的方式保持了本地环境和云端环境的高度一致，解决了运维人员的一大心病，将运维人员从一遍遍的重复劳动中解放了出来。同时友好简洁的封装，对开发人员十分具有亲和力，这让Docker一举走红。很多后端和云计算领域的优秀的开发力量都汇集在了Docker的周围，生态一时间变得异常繁荣。

但此时的这个开源创业公司还必须考虑盈利压力，于是dot Cloud公司决定将公司名称改为“Docker”。将这个开源项目的名称变成了Docker公司的注册商标，这意味着，任何人在商业活动中使用这个单词，以及鲸鱼的Logo，都会立刻受到法律警告。

2014年到2015年期间，是容器技术的鼎盛时期，Docker公司一家独大，具有十足的话语权，主导着整个社区的发展。Google公司曾向Docker公司表达了合作的愿望，希望共同推进一个中立的容器运行时（container runtime）库作为Docker项目的核心依赖。不过，Docker公司并没有认同这个明显会削弱自己地位的提议，不久后Docker自己还发布了一个容器运行时库Libcontainer。

作为开源生态的一部分，Docker还缺少有效的商业模式，他们将眼光放到了容器编排领域，推出了Swarm。作为Docker项目早期的重要贡献者，Red Hat对Docker公司的这个平台化战略表示很不满并愤愤退出该项目。

面对Docker的强硬态度，Google联合Red Hat，共同牵头发起了一个名为CNCF （Cloud Native Computing Foundation）的中立基金会，来推动Kubernetes的发展。

从此之后，面对Kubernetes社区的崛起和壮大，Docker公司不得不面对失败的现实。2017年Docker公司宣布将Docker项目改名为Moby，交给社区自行维护，而Docker公司的商业产品将占有Docker这个注册商标，希望以此将原本属于Docker社区的用户转化成了自己的客户。

杨明越认为现在的Kubernetes，从技术上可以说是非常开放的产物，但Docker已经不是。开源社区的Moby项目，图标由一条鲸鱼变成了一条鲸鱼的尾巴，也可以看出Docker对开源版本的态度。原本是开源的项目，是开源生态的一部分，盈利的目标对于Docker来说，属于“强扭的瓜”。正如人际关系，从风雨同舟到分道扬镳，甚至到反目成仇，这其中的转折点，并非一两次冲突，而是价值取向的背离。

他强调说：“总体来说，Docker的弱势来自于公司的盈利、技术应用面两方面，但如果谈Docker的消亡，还为时过早。因为Docker本身也是一系列技术模块的组合体系，而非一个东西。”

王新勇也认为Docker技术（或者说Moby项目）和Docker公司得分开看待。短时间内，Moby项目不会消亡，会使用Docker命令可能会成为一个开发人员的必备技能，毕竟技术的惯性是很强大的。至于Docker公司，就算处境不乐观，应该也是不影响Docker技术本身的，毕竟其背后还有强大的开源社区。

云原生技术的未来

近几年，云原生技术发展速度很快，“Kubernetes 1.20版本中弃用Docker支持”可能只是其中很小的一段插曲，毕竟在云原生的全局图中，运行时只占很小的一部分，而且又是比较标准化的部分。

“从云原生的角度来看Kubernetes弃用Docker，其实是件好事，”杨明越表示：“Docker已经是个商业化产品了，如果能找到一个开源替代品，对整个技术的发展会更有益处。”那么，谁将会代替Docker成为云原生技术的“新势力”呢？在我们的采访中，多位老师表示很看好Podman。

Podman（Pod Manager）是一个由Red Hat公司推出的容器管理工具，其定位就是Docker的替代品，在使用上与Docker的体验类似。Podman源于CRI-O项目，可以直接访问OCI的实现（如run C），流程比Docker要短。

为什么说Podman是比Docker更先进的存在呢？晓川表示：“首先，Docker已经是商业化的产品，而podman是个开源产品，在以开源为主的云原生技术体系中更容易得到推广和应用；其次，Docker在实现CRI时，需要一个守护进程，并且以root来运行，这就带来了安全隐患，而podman不需要，可以直接通过OCI runtime（默认也是runc）来启动容器。”

由于podman的定位是Docker的替代品，因此在使用习惯方面也与Docker十分类似。

从系统构建者角度看，podman默认软件与Docker的区别不大，只是在进程模型、进程关系方面有所区别，例如关联进程的调试方面、进程的树状结构查看等等，而且总体来看，podman要比Docker简单；从使用者角度看，podman与Docker的命令基本兼容，包括容器运行时、本地镜像、镜像仓库等。因此，podman命令行工具与docker类似，比如构建镜像、启停容器等，甚至可以通过alias docker=podman可以进行替换，即便使用了podman，仍然可以使用docker.io作为镜像仓库。

除了Kubernetes，RHEL 7同样官方也不支持Docker，只为容器环境提供Podman、Buildah以及CRI-O。

采访嘉宾：

杨明越，现从事分布式系统、云架构方面工作，具有全方位的技术，曾任新兴互联网公司（BAT）的主任架构师，世界顶级芯片公司的OS技术专家，前Top2通讯公司高级工程师。

王新勇，网易数帆资深架构师，网易轻舟容器平台NCS负责人。

晓川，曾在Red Hat任产品测试开发工程师，具有多年Docker容器、K8s、Linux和Python方面的经验，在Open Shift从事Paa S平台比较前沿的技术项目。