共计 2805 个字符，预计需要花费 8 分钟才能阅读完成。
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 具备更强的生命力。
