kubernetes 1.20中对于docker的弃用，引发的探讨很多，对于docker兴起的话题又热了起来。对这一事件，咱们找了OPPO一位工程师大佬，从技术人员的角度说说这个事。他自己2014年开始从事容器化相干工作，目前负责OPPO云平台的编排与调度方向的工作。

随同着kubernetes 1.20中对于docker的弃用，对于docker的灭亡与kubernetes的衰亡的话题再度热了起来。探讨中对于docker灭亡的观点我不敢苟同。docker还远未达到灭亡的水平。相较而言，我感觉更失当的说法应该是docker的衰败。本文我也就我集体的角度，聊聊我所经验的docker的衰败与kubernetes的衰亡。

横空出世——docker的衰亡

第一次接触docker，是2014年。过后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具备更强的生命力。