关于云原生-cloud-native:容器技术之发展简史

4次阅读

共计 10624 个字符，预计需要花费 27 分钟才能阅读完成。

简介： 容器技术催生了云原生思潮，云原生生态推动了容器技术倒退。整顿容器技术近 20 年的倒退历史，大抵能够将其分为四个历史阶段。

作者 | 刘奖

“云原生技术有利于各组织在 私有云、公有云和混合云 等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含 容器、服务网格、微服务、不可变基础设施和申明式 API。”

聊容器技术避不开云原生，聊云原生也避不开容器技术。容器技术和云原生就是一对双螺旋体，容器技术催生了云原生思潮，云原生生态推动了容器技术倒退。从 2013 年 docker（container）技术诞生，到 2015 年 CNCF 这个云原生畛域重量级联盟便成立，这不是历史的偶合而是历史的必然。作为云原生关键技术之一的容器，从 2013 年诞生以来始终是行业关注的焦点之一。借用一张业界宽泛援用的云原生容器技术进阶图来理解一下容器技术和云原生诞生的历史背景。

先让咱们一起来看看容器技术倒退的历史纪年表，先直观感受一下这片热火朝天的热土吧！

1979 年，Unix v7 零碎反对 chroot，为利用构建一个独立的虚构文件系统视图。
1999 年，FreeBSD 4.0 反对 jail，第一个商用化的 OS 虚拟化技术。
2004 年，Solaris 10 反对 Solaris Zone，第二个商用化的 OS 虚拟化技术。
2005 年，OpenVZ 公布，十分重要的 Linux OS 虚拟化技术先行者。
2004 年 ~ 2007 年，Google 外部大规模应用 Cgroups 等的 OS 虚拟化技术。
2006 年，Google 开源外部应用的 process container 技术，后续更名为 cgroup。
2008 年，Cgroups 进入了 Linux 内核主线。
2008 年，LXC（Linux Container）我的项目具备了 Linux 容器的雏型。
2011 年，CloudFoundry 开发 Warden 零碎，一个残缺的容器管理系统雏型。
2013 年，Google 通过 Let Me Contain That For You (LMCTFY) 开源外部容器零碎。
2013 年，Docker 我的项目正式公布，让 Linux 容器技术逐渐席卷天下。
2014 年，Kubernetes 我的项目正式公布，容器技术开始和编排零碎起头并进。
2015 年，由 Google，Redhat、Microsoft 及一些大型云厂商独特创建了 CNCF，云原生浪潮启动。
2016 年 – 2017 年，容器生态开始模块化、规范化。CNCF 承受 Containerd、rkt 我的项目，OCI 公布 1.0，CRI/CNI 失去广泛支持。
2017 年 – 2018 年，容器服务商业化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，华为 CCI，Oracle Container Engine for Kubernetes；VMware，Redhat 和 Rancher 开始提供基于 Kubernetes 的商业服务产品。
2017 年 – 2019 年，容器引擎技术飞速发展，新技术不断涌现。2017 年底 Kata Containers 社区成立，2018 年 5 月 Google 开源 gVisor 代码，2018 年 11 月 AWS 开源 firecracker，阿里云公布平安沙箱 1.0。
2020 年 – 202x 年，容器引擎技术升级，Kata Containers 开始 2.0 架构，阿里云公布沙箱容器 2.0….

整顿容器技术近 20 年的倒退历史，大抵能够将其分为四个历史阶段，下文将具体介绍这四个历史阶段。

容器技术须要解决的外围问题之一是运行时的环境隔离。

容器的运行时环境隔离，指标是给容器结构一个无差别的运行时环境，用以在任意工夫、任意地位运行容器镜像。因为 docker 的布道，大家习惯性认为容器的运行时环境隔离就是 OS 虚拟化，或者容器等于 namespace + cgroup + 平安防护机制。我不太同意这种认识，这个只是一段历史期间、一种容器运行时的实现技术，还有很多种其它可能的技术计划来实现容器运行环境。所以，回到需要的根源：容器须要运行时隔离技术来保障容器的运行环境合乎预期。习惯上，大家把这种实现容器隔离技术的组件叫做容器运行时。

从另外一个角度看，容器隔离技术解决的是资源供应问题。为啥须要容器隔离技术来解决资源供应问题呢？成也萧何，败也萧何！摩尔定律切实太过弱小，它让咱们有了越来越多的计算资源能够应用。10 年前做小型机时，小型机的典型规格是 32 路 8 核 CPU，当初一台 4 路 PC 服务器计算能力都超过 10 年前的小型机服务器。小型机的典型用法是把整机切分为多个分区应用。察看当下云服务硬件发展趋势，越来越有相熟的感觉，咱们在把小型机相干技术“军转民”。当初咱们一台 PC 服务器领有了十分弱小的、能和十年前小型机媲美的计算能力，偶合的是当下 PC 服务器的典型用法也和十年前的小型机用法相似，切割为 1-8vCPU 的虚拟机 / 容器应用。

为什么人们总是习惯于把一个大的服务器资源切分为小的分区应用而不是研发可能充分发挥大型服务器整机计算能力的软件呢？集体认为背地有两个制约因素：

待解决问题自身外在的并行度无限。随着多核多处理器零碎的日益遍及，IT 行业从 2004 年开始进行串行编程到并行编程的降级革新。开始阶段针对特定行业利用的并行化革新成果非常明显，然而起初发现随着并行度进步革新老本越来越大、收益却越来越低。受阿姆达尔定律制约，解决特定问题的并行度超过肯定临界点之后收益将逐步变小。所以一味进步零碎并行度并不是经济的做法。
人类智力无限。受人类智力限度，零碎越简单、并行度越高，软件越容易出故障，软件维护代价成指数级增长。所以，从软件工程看，大家也趋向于接口化、模块化、单元化的软件架构设计，尽量控制软件的复杂度，升高工程老本。

从教训看，1-8 个 CPU 的并行度是软件工程的舒服区，这个也是容器化、微服务等技术背地的驱动因素之一。

有点跑题了。。。总之，基于隔离的资源供应不是伪需要。对于软件运行环境的隔离要求，从操作系统呈现之初就有了。多任务分时操作系统和过程虚拟地址都是为了解决多个工作运行在同一台主机上的资源共享问题，让每个过程都认为本人独占主机。当然仅仅是过程隔离是远远不够的。纵观以后的资源隔离技术，咱们大抵能够将资源隔离技术分成 5 类：

过程隔离。OS 以过程作为 Task 运行过程的形象，过程领有独立的地址空间和执行上下文，实质上 OS 对过程进行了 CPU 和内存虚拟化。然而过程之间还共享了文件系统、网络协议栈、IPC 通信空间等多种资源，过程之间因为资源争抢导致的烦扰很重大。这个层级的隔离适宜在不同的主机上运行单个用户的不同程序，由用户通过系统管理伎俩来保障资源分配与平安防护等问题。
OS 虚拟化。OS 隔离，也就是大家常说的操作系统虚拟化（OS virtualization），是过程隔离的升华版。过程隔离是为每个过程实现了独自的地址空间及 CPU 上下文，OS 隔离则是利用操作系统分身术为每一组过程实例结构出一个独立的 OS 环境，以进一步虚拟化文件系统、网络协议栈、IPC 通信空间、过程 ID、用户 ID 等 OS 资源。OS 隔离须要解决三个外围问题：独立视图、访问控制及平安防护。Chroot、Linux namespace 机制为过程组实现独立视图，cgroup 对过程组进行访问控制，而 Capabilities、Apparmor、seccomp 等机制则实现平安防护。当然，OS 是一个非常复杂、动态变化的零碎，OS 分身术尽管让过程组感觉有了独立的 OS，然而实在实现还是一个 OS 实例，所以整体防护能力还是堪忧。
硬件虚拟化。OS 虚拟化是实现 OS 内核的分身术，而硬件虚拟化则是实现硬件设施的分身术。硬件虚拟化技术的呈现，让同一个物理服务器上可能同时运行多个操作系统，每个操作系统都认为本人在治理一台残缺的服务器。不同操作系统之间是严格隔离的，Guest 操作系统对硬件的拜访都是受 VMM 或 CPU 的严格监管的。硬件虚拟化既有很好的安全性，也有很好的隔离性，毛病就是引入的硬件虚拟化层导致了额定的性能开销。
硬件分区。这个是传统小型机体系采纳的资源分隔技术，就是从硬件或固件层彻底把一台大型服务器分隔为多个硬件单元，从而取得最高等级的安全性和隔离性。然而小型机作为一个逐渐败落的技术路线，其不足之处还是不言而喻的：资源分隔粒度不灵便、零碎老本偏高、零碎可扩展性受限。
语言运行时隔离。对于 Java、nodejs 等须要 language runtime 的 managed language，咱们还有一个选项，就是在 language runtime 里实现隔离。针对函数计算等云原生服务，实践上在语言运行时实现隔离机制是最优门路。然而这条路线目前实现上还有不少事实的制约，所以目前少数函数计算还是采纳的容器 / VM 技术来实现的隔离。

在 OS 虚拟化这条技术路线上，最大的技术奉献来源于 Google。

2003 – 2006 年，Google 陆续公布的“三驾马车”，奠定了大数据计算的框架，随后进一步发明了“云”的概念。也是从这期间开始，过程隔离技术进入了一个更高级的阶段。在 Google 提出的云计算框架下，被隔离的过程不仅仅是一个与外界断绝但自身却巍然不动的 Jail，它们更须要像一个个轻便的容器，除了可能与外界隔离之外，还要可能被管制与调配，从而实现分布式应用场景下的跨平台、高可用、可扩大等个性。

2006 年，Google 推出 Process Containers，用来对一组过程进行限度、记账、隔离资源（CPU、内存、磁盘 I/O、网络等）。因为技术更加成熟，Process Container 在 2006 年正式推出后，第二年就进入了 Linux 内核骨干，并正式更名为 Cgroups，标记着 Linux 营垒中“容器”的概念开始被从新扫视和实现。

在 2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace（命名空间）的视图隔离能力组合在一起，一项残缺的容器技术 LXC（Linux Container）呈现在了 Linux 内核中，这就是现在被广泛应用的容器技术的实现根底。

总体看，在 2013 年 docker 被创造以前，Linux 操作系统曾经大体上解决了容器核心技术之一的运行环境隔离技术，或者说 Linux OS 虚拟化技术曾经基本上成型了。尽管容器运行环境隔离技术曾经根本就位，咱们仍需期待另外一项关键技术能力迎来容器技术的腾飞时刻。

2013 年之前，云计算行业始终在为云原生的正确关上姿态而操心。Platform as a Service（PaaS）看起来是个有前途的方向。2006 年 Fotango 公司公布的 Zimi 服务，能够说是 PaaS 行业的鼻祖，具备按应用付费、免运维（Serverless）、API 化配置和服务等典型云原生的特色；2008 年 Google 推出 GAE；2011 年 Pivotal 公布 Cloud Foundry。这些晚期的 PaaS 平台进行了十分无益的摸索，推动了云计算生态的衰弱倒退，然而这些晚期摸索技术并没有造成大的行业趋势，而是局限在一些的特定的畛域。直到 Docker 开源，大家才如梦方醒，原来不是方向不对，而是利用散发和交付的伎俩不行。

Docker 真正外围的翻新是容器镜像（docker image），一种新型的利用打包、散发和运行机制。容器镜像将利用 运行环境 ，包含代码、依赖库、工具、资源文件和元信息等，打包成一种 操作系统发行版 无关的 不可变更 软件包。

容器镜像打包了整个容器运行依赖的环境，以防止依赖运行容器的服务器的操作系统，从而实现“build once，run anywhere”。
容器镜像一旦构建实现，就变成 read only，成为不可变基础设施的一份子。
操作系统发行版无关，外围解决的是容器过程对操作系统蕴含的库、工具、配置的依赖，然而容器镜像无奈解决容器过程对内核个性的非凡依赖。这个在理论应用容器的过程中也常常跳进这个大坑：

Docker 的宣传口号是“Build，Ship and Run Any App，Anywhere”。咱们曾经了解了 docker 通过 container image 解决“Run Anywhere”的机制，那么“Run Any App”是如何实现的呢？其实也是依赖 container image，用户能够打包任何容器过程所依赖的环境，而不必革新利用来适配 PaaS 定义的运行环境。真是“Run Any App”一举突破了 PaaS 行业面临的窘境，发明出了有限的可能性，鼎力推动了云原生的倒退。让咱们一起来向这个平凡的创意致敬！

至此，容器技术体系曾经解决了最外围的两个问题：如何公布软件 和如何运行软件，腾飞时刻行将到来。2014 年前司前老板对我说“别成天搞 Linux kernel 了，要不你看看 docker？”通过短暂的调研，我给了前老板一个简略而清晰的答复，“无它，唯打包工具尔！”因为这个答复，云原生为我关上的一扇大门就轻轻关上了。回忆一下历史，有时也挺后悔的，因为本人太年老而没有看清楚容器技术 + 编排零碎的威力，更没有领会到云原生行将到来的气味！

Docker 作为一个单机软件打包、公布、运行零碎，其价值是十分微小的；然而仅仅将 docker 技术局限在单机范畴不能施展这个翻新技术的最大价值，天然下一步业界心愿基于 docker 技术构建一个云化的集群零碎，来对业务容器进行编排治理。

聊到容器编排零碎，咱们须要从 Google 聊起。2008 年，Google 基于 LXC 推出首款利用托管平台 GAE（Google App Engine），首次把开发平台当做一种服务来提供。

GAE 是一种分布式平台服务，Google 通过虚拟化技术为用户提供开发环境、服务器平台、硬件资源等服务，用户能够在平台根底上定制开发本人的应用程序并通过 Google 的服务器和互联网资源进行散发。Google 在 GAE 中应用了一个可能对 LXC 进行编排和调度的工具 —— Borg（Kubernetes 的前身）。Borg 是 Google 外部应用的大规模集群管理系统，能够承载十万级的工作、数千个不同的利用、同时治理数万台机器。Borg 通过权限治理、资源共享、性能隔离等来达到高资源利用率。它可能反对高可用利用，并通过调度策略缩小呈现故障的概率，提供了工作描述语言、实时工作监控、剖析工具等。如果说一个个隔离的容器是集装箱，那么 Borg 能够说是最早的港口零碎，而 LXC + Borg 就是最早的容器编排框架。

2013 年 docker 推出之后迅速席卷寰球，2014 年 Google 基于外部应用的 Borg 零碎创立了开源我的项目 Kubernetes（简称 K8s），用于解决大规模集群的容器部署、运行、治理等问题。Kubernetes 在容器的根底上减少了一层的新的治理形象 Pod，以便更好地利用容器进行利用的功能模块切分。得益于 Google 在大规模集群基础设施建设的弱小积攒，脱胎于 Borg 的 K8s 很快成为了行业的规范利用，堪称容器编排的必备工具。

作为回应，Docker 公司在 2015 年公布的 Docker 1.12 版本中也退出了一个容器集群管理系统 Docker swarm，以及配套的 Docker machine、Docker Compose 等工具，力求构建欠缺的容器编排零碎，和 Kubernetes 开展侧面竞争。从此，容器江湖分为两大阵营：Google 派和 Docker 派；而容器编排零碎则是 Kubernetes，Docker Swarm 和 Apache Mesos 三国并立。各大派别的竞争愈演愈烈，逐步延长到行业标准的建设之争。让咱们一起来回顾一下这段风起云涌的江湖历史吧！

2013 年 Docker 公司推出 docker 之后，紧接着 CoreOS 应运而生。CoreOS 是一个基于 Linux 内核的轻量级操作系统，专为云计算时代计算机集群的基础设施建设而设计，领有自动化、易部署、安全可靠、规模化等个性。其在过后有一个十分显眼的标签：专为容器设计的操作系统 。借着 Docker 的东风，CoreOS 迅速在云计算畛域蹿红，一时间，Docker + CoreOS 成为业内容器部署的黄金搭档。
同时，CoreOS 也为 Docker 的推广与社区建设做出了微小的奉献。然而，日渐壮大的 Docker 仿佛有着更大的“野心”。不甘于只做“一种简略的根底单元”的 Docker，自行开发了一系列相干的容器组件，同时收买了一些容器化技术的公司，开始打造属于本人的容器生态平台。显然，这对于 CoreOS 来说造成了间接的竞争关系。2014 年末，CoreOS 推出了本人的容器引擎 Rocket（简称 rkt），试图与 Docker 分庭抗礼。rkt 和 Docker 相似，都能帮忙开发者打包利用和依赖包到可移植容器中，简化搭环境等部署工作。rkt 和 Docker 不同的中央在于，rkt 没有 Docker 那些为企业用户提供的“敌对性能”，比方云服务减速工具、集群零碎等。反过来说，rkt 想做的，是一个更纯正的业界规范。

下面这段资料引至于“从虚拟化到云原生——容器技术的发展史”，为什么大段大段地援用这部分资料呢？这外面最要害的脉络是 因为技术公司之间的商业竞争，在竞争单干之间寻找均衡从而导致了标准规范的诞生，而标准规范的诞生是整个云原生生态最重要的基石。

容器引擎（docker vs rocket）、容器编排（Docker swarm vs Kubernetes vs Apache Mesos）的相互竞争的后果就是大家坐下来谈接口标准。2015 年 6 月，Docker 带头成立 OCI，旨在“制订并保护容器镜像格局和容器运行时的正式标准（OCI Specifications）”，其外围产出是 OCI Runtime Spec（容器运行时标准）、OCI Image Spec（镜像格局标准）、OCI Distribution Spec（镜像散发标准）。所以 OCI 组织解决的是容器的构建、散发和运行问题。

一个月之后，Google 带头成立了 Cloud Native Computing Foundation（CNCF），旨在“构建云原生计算 —— 一种围绕着微服务、容器和利用动静调度的、以基础设施为核心的架构，并促成其宽泛应用”。所以 CNCF 组织解决的是利用治理及容器编排问题。这两个围绕容器的基金会对云原生生态的倒退施展了十分重要的作用，二者不是竞争而是相辅相成，独特制订了一系列行业事实标准。这些行业事实标准的确立，各行业注入了有限生机，基于接口的规范的具体实现不断涌现，呈现出一片百花齐放的现象。

其中，与容器相干的最为重要的几个标准包含：CRI、CNI、CSI、OCI Distribution Spec、OCI Image Spec、OCI Runtime Spec 和 Shimv2。其中的 CRI、OCI Image Spec、OCI Runtime 和 Shimv2 标准和阿里云沙箱容器关系十分亲密。

所以，非常感谢这个云原生、容器技术爆发的黄金期，一群有创意的人走到一起独特发明了这几个要害的标准，为各个厂商提供各具特色且遵循标准的技术实现提供了可能性。

通过 5 年的技术发展期，容器技术根本成熟，云原生体系也具雏型。从 2017 年开始，各大云厂商开始试水容器服务及提高的云原生服务。从目前的商业状态看，容器相干的公共云服务大抵能够划分为三种状态：

通用容器编排服务。在容器编排零碎三国杀后果进去以前，基于多方下注策略构建的容器编排服务零碎。其中 AWS 是自研的编排零碎，Azure 的 ACS 同时反对 Docker Swarm、DC/OS 和 Kubernetes，阿里云 ACS 则是反对 Docker swarm 和 Kubernetes。Google 和华为则是动摇反对 Kubernetes 而未推出反对其它容器编排零碎的容器服务。随着 Kubernetes 一统容器编排江湖，这条路线的容器服务日渐式微，Azure 更是在今年初间接终止了 ACS 服务。
Kubernetes 容器编排服务。Google 是天经地义最早试水 Kubernetes 容器编排服务的大厂，也较早发展了 K8s 容器编排服务。随着 2017 年各大厂在 CNCF 这张谈判桌上达成了 Kubernetes 兼容性认证流程，Kubernetes 编排服务市场迎来一轮大暴发，到 2018 年各大云厂商的 K8s 容器编排服务就残缺就位了。
Serverless 容器实例服务。从 2017 年开始，行业开始试水 Serverless 容器实例服务，把用户从保护容器基础设施的沉重工作中解放出来从而聚焦业务自身。Google Cloud Run 外围指标是反对 Knative，所以其应用状态上附加了不少约束条件。

从上图能够看出，从 2014 年开始摸索公共云容器服务，特地是通过 2017 – 2018 年这两年的抢跑期，容器服务的根本商业状态曾经比拟清晰了。倒退态势能够概括为：

行业对容器化的接受程度曾经很高，容器化普及率也是逐年晋升。
容器编排零碎曾经一战定江山，K8s 成为事实上的容器编排之王。
Serverless 容器实例服务受到市场的欢送，客户群体日益扩充。
长期看托管容器编排服务和 Serverless 容器实例服务将长期共存，协同满足客户对服务老本和弹性能力的需要。

商用模式摸索期间，外围指标是疾速试错疏导和确认客户需要，构建实用的产品状态。这个期间的产品技术架构的构建思路是利用现有成熟技术疾速搭建商用状态，在试错过程中一直前行。

其中，容器编排托管服务节点级的典型架构是利用 IaaS 系统生成 VM，而后在 VM 外面部署 kubelet、docker、containerd、runC 等容器服务组件，也就是 VM + 容器的技术架构 。一个 VM 能够承载同一个用户的多个容器 / Pod 实例。而 Serverless 容器实例服务的节点级架构更间接， 在一个 VM 外面只部署一个容器 / Pod 实例，从而实现 Serverless。这种短平快的打法疾速推动了商用模型的摸索，起到了十分重要的历史作用，然而其在弹性能力、部署密度、资源老本方面的历史局限性还是很大的。

到 2019 年，容器服务的商业状态以及市场趋势曾经很显著了，行业整体进入了商业拓展阶段，对外宣传吸引更多的客户群体，对内苦练内功晋升产品技术竞争力，行业正在经验从“有”到“优”的技术升级。行业正在经验这个技术升级的历史阶段，还谈不上论断，只能一起来聊聊趋势及预判。本系列专题的关注点是容器隔离技术，所以先不聊商业拓展和容器编排而聚焦于容器引擎技术发展趋势。到当初为止，咱们大体上能够把容器引擎技术划分为两代：

Container on VM。也就是依照分层设计思路，通过 IaaS + PaaS 的架构构建容器服务，这个是商用摸索阶段的典型架构。基于各大云厂商成熟的 IaaS 基础设施生产虚拟机，在虚拟机外面部署容器服务组件。这种架构采纳的是 lift and shift 策略，把容器服务的运维责任从用户转移到云厂商。采纳和用户雷同的软件组件，只是转移运维责任，有利于疏导客户逐渐上云、承受云原生思维。然而这个期间云厂商提供的服务是单纯的运维托管，绝对用户自建容器服务并没有太显著的技术劣势，甚至受多租户隔离的限度局部应用体验还不如用户自建容器服务。
Container with hardware virtualization。如果沿用 Container on VM 的分层设计架构，云厂商很难构建独有的技术劣势。对于 Serverless 容器实例服务，服务交付立体曾经从 IaaS 的硬件接口上移到 OS Syscall，所以不要遵循 VM + 容器的分层设计思路。咱们须要从需要根源登程，容器服务须要高性能、强隔离、够平安和低成本的容器引擎。以后行业研发热点之一就是如何构建这样一个容器引擎，具体技术思路请注意后续系列文章。

总结来看，容器服务生态大略经验了四个阶段，别离解决或试图解决不同的问题：

技术萌芽期：解决了容器运行环境的隔离问题
技术爆发期：解决了软件散发及容器编排问题
商用探索期：确认了容器的商用服务状态
商用拓展期：扩充实用场景和部署规模，通过技术创新晋升产品竞争力

聊了这么多历史，让咱们再来闲聊一下 docker 这个公司和 docker 这门技术吧！

2019 年 11 月 13 日，公有云基础设施公司 Mirantis 在其官网博客发表，收买 Docker 公司企业级业务，包含接管它的 700 多个客户，这标记着 Docker 公司从 2013 年开始的商业化摸索彻底失败。在不理解容器倒退历史的人看来，这种后果很难了解，Docker 是容器热潮的开创者，容器则是这一轮云计算技术演进的开启者，为什么明明站在风口上了，却依然飞不起来？

其实，Docker 明天的命运，在 4 年前就决定了。

2014 年 Kubernetes 公布后，迅速吸引了包含 Redhat 在内的一批重量级成员，并在一年之后迅速公布 Kubernetes 1.0 以撑持正式商用。作为回应 Docker 公司主导成立了 OCI，旨在为容器镜像格局和运行时制订一个凋谢规范，从而持续占据容器生态的话语权。然而 2015 年 7 月 CNCF 成立之后，迅速弯道超车开拓新的战场，主攻容器编排与利用治理。随后 2016 年 Kubernetes 社区制订了容器运行时的接口标准 CRI，只有实现这个 CRI 标准的容器运行时就能够和 K8s 生态对接，从引发了容器引擎的研发热潮。cri-containerd，cri-o，frakti 等引擎不断涌现，加上原有的 rkt 引擎，docker 变成了容器引擎芸芸众生中的一员。从哪儿来到哪儿去，docker 又回到了最后的状态，一个单机版软件打包运行工具，基本上完满错过了云原生浪潮。

然而在相当长的期间内，docker 这个客户端容器管理工具（UI）还是会长期存在的，毕竟弱小的用户群体在哪儿。然而在云服务厂商的技术栈中，docker 的位置会越来越弱，逐渐被 K8s 专用的容器引擎代替。尽管当初 docker 的大众根底仍然弱小，然而星星之火曾经点燃，趋势未然浮现，剩下的只是工夫问题！