观察|漫话docker的衰落与kubernetes的兴起

本文来自OPPO云平台团队高级工程师徐工，他自2014年开始从事容器化相关工作，目前负责OPPO云平台的编排与调度方向的工作，主要关注技术领域为超大规模的集群管理与调度，混合云平台建设与融合计算。

伴随着kubernetes 1.20中对于docker的弃用，关于docker的灭亡与kubernetes的兴起的话题再度热了起来。讨论中关于docker灭亡的观点我不敢苟同。docker还远未到达灭亡的程度。相较而言，我觉得更恰当的说法应该是docker的衰落。本文我也就我个人的角度，聊聊我所经历的docker的衰落与kubernetes的兴起。

横空出世——docker的兴起

还记得2014年吗？那是我第一次接触docker。当时OpenStack的主要负载还是kvm，我们也尝试过更轻量的lxc，不过最后失败了。而docker呢，那个集装箱小图标，再加上docker container的理念，一下子就抓住了大家的心。只有经历过制作lxc镜像的痛苦，才能真正体会到docker的好。繁琐的lxc镜像制作，和精简的Dockerfile相比，谁好谁坏、谁高谁低，那可真是一目了然啊。

docker成功的将cgroup、union filesystem、namespace这些较为稳定和成熟的技术结合了起来，辅以docker image的制作工艺，实现了集装箱式的标准交付。

这时候的docker，颇有种“举天下之豪杰而莫能与之争”的气势。虽然在生产环节还是或多或少，还有这样那样的问题，但是docker已经跨过了POC（Proof of concept）阶段，进入了pre-product的行列了。在对docker深度定制后，最终我们团队也将OpenStack + docker的组合成功推向了生产。

那两年，知不知道docker、会不会做镜像、懂不懂docker原理成为基础架构领域面试的常见话题。虽然只有少数几个公司敢为天下先，将docker搬上了生产，但是已经没有人可以忽略这颗冉冉升起的新星了。

那时活跃在各个会议、论坛上的都是docker的话题。大家热衷于讨论生产上docker遇到的坑。大家各出奇招，修修补补，跌跌撞撞，docker总算也是被搬上了生产。而在这时，即使是技术保守、持徘徊观望态度的公司，也都会安排一些人力着手跟进docker的发展与各个公司的实践经验了，这时候的docker真的是风头无两。

生来巨人——kubernetes

时间到了2015年，此时我转而负责进行CaaS（Container as a Service）服务的调研。这时候大家都在说CaaS，但是每个人说的都不一样，其实大家都是摸着石头过河。在此期间，以研究OpenStack的magnum为契机，我接触到了swarm和kubernetes。

swarm是docker公司力推的集群管理方案。docker、swarm和compose组成的三剑客完整覆盖了运行时、集群管理与编排，构成了一个看起来牢不可摧的生态系统。特别是别出心裁的将swarm的api与docker的api进行了拉齐，将集群的管理复杂度与单节点的管理复杂度向用户进行屏蔽，倒是有一种如臂使指的快感。这个设计直到现在我都还觉得立意真的很精巧。

而初出茅庐的kubernetes也来势汹汹。背靠Google的大旗，有Borg的背书，kubernetes在气势上一点不输swarm + compose的组合。伴随着kubernetes 1.0的发布，kubernetes也从幕后走向了台前，开始大规模接受来自全世界的PR提交，在功能、性能和稳定性上快速提升。

到kubernetes 1.2版本，经过我们内部评估，已经具备生产级的品质。而声明式API、简洁的架构、灵活的标签等优秀的设计，在做选型时已经让我们完全没有理由拒绝。而后经过数月紧张的开发，kubernetes + docker的组合被搬上了舞台，并且以极快的速度侵蚀OpenStack + docker的份额。

此时的docker已经开始被限制为了容器的运行时和镜像制作工具。捆住了docker的手脚，kubernetes已经没有了可以掰手腕的对手，一统江湖的路上kubernetes再无障碍。

美人迟暮——docker的衰落

时至今日，docker的衰落已经成为了不争的事实，而造成这个结果的原因，我觉得是多方面的。

一部分是docker自身的封闭和固执己见。我曾经记得在当时参与了当时社区多个PR的讨论。新增一个feature的超长的周期，已经可以磨掉多数人的耐心。docker社区在多个观点上略显保守的方式，让大家逐渐失去了参与的热情。

另一个方面，且更为关键的是，容器技术本身的门槛已然被跨越，不再能构建起技术上的护城河。而容器技术的竞争，已然转变为标准的竞争，对于在标准方面拥有更多话语权的一方，无疑是拥有更多用户、更庞大社区以及更强大平台的一方。在短短两三年的时间里，天平迅速向kubernetes倾斜，其主导的CRI、CNI、CSI标准已然成为事实上的通行标准。相比之下，docker大力推动的CNM等标准则显得过于小众。

与此同时，kubernetes并没有放弃主动的进攻。kubernetes的强势和扶植其他容器运行时加速了docker的衰落。在1.6版本弃用docker manager直连docker，转向CRI + dockershim的组合时，就注定了kubernetes会走到完全解耦docker，也就是今天这一步。

另外，其他容器运行时也开始了瓜分市场份额。如果说gVisor、Kata只是尝试挑战docker在部分场景中的地位，那么红帽的Podman则已经吹响了全面进攻的号角。再结合前两年docker的一些融资和收购传闻，平添了一种英雄末路、美人迟暮的伤感。

回顾

世间多少英雄戏，每到收场总伤神。

六年回望，其实无论是在当时还是现在来看，docker都是一个革命性的产品。docker的衰落并不是意味着容器运行时不重要了，而是大家越来越习以为常了。

时至今日，容器运行时作为一个大部已经被解决的问题，一个相对成熟的模块，已经成为了整个基础架构体系的一部分。而作为上层的平台和更为上层的用户来说，对此将会给予越来越少的关注，这就像现在大多数用户并不会去关心内核了一样。

甚至在未来，我预测运行时都有可能会成为一个内核级别的附属模块，会预装到许多的发行版上，其运行也逐渐对大多数用户变得更加透明（实际红帽已经开始向这个方向做了）。而越来越多的用户则会将更多的注意力集中在上层的交付、管理、编排上。

至于kubernetes会不会衰落，我觉得在中短期内（五年内）不会。kubernetes已经成为了一个平台级的项目。在这点上，kubernetes作为平台将比工具性质的docker具有更强的生命力。

☆END☆

OPPO互联网云平台团队招聘一大波岗位，涵盖Ja va、容器、Linux内核开发、产品经理、项目经理等多个方向，请在公众号后台回复关键词“云招聘”查看查详细信息。

如何用 CI (持续集成) 保证研发质量

如何设计并实现存储QoS？

云原生Service Mesh探索与实践

如何进行 kubernetes 问题的排障

OPPO自研ESA DataFlow架构与实践

更多技术干货

扫码关注

OPPO互联网技术

本文分享自微信公众号 - OPPO互联网技术（OPPO_tech）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。