容器技术之发展简史

做者 | 刘奖

背景

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的表明技术包括容器、服务网格、微服务、不可变基础设施和声明式 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 年开始，各大云厂商开始试水容器服务及进步的云原生服务。从目前的商业形态看，容器相关的公共云服务大体能够划分为三种形态：

1. 通用容器编排服务。在容器编排系统三国杀结果出来之前，基于多方下注策略构建的容器编排服务系统。其中 AWS 是自研的编排系统，Azure 的 ACS 同时支持 Docker Swarm、DC/OS 和 Kubernetes，阿里云 ACS 则是支持 Docker swarm 和 Kubernetes。Google 和华为则是坚决支持 Kubernetes 而未推出支持其它容器编排系统的容器服务。随着 Kubernetes 一统容器编排江湖，这条路线的容器服务日渐式微，Azure 更是在今年初直接终止了 ACS 服务。
2. Kubernetes 容器编排服务。Google 是理所固然最先试水 Kubernetes 容器编排服务的大厂，也较早开展了 K8s 容器编排服务。随着 2017 年各大厂在 CNCF 这张谈判桌上达成了 Kubernetes 兼容性认证流程，Kubernetes 编排服务市场迎来一轮大爆发，到 2018 年各大云厂商的 K8s 容器编排服务就完整就位了。
3. 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 年，容器服务的商业形态以及市场趋势已经很明显了，行业总体进入了商业拓展阶段，对外宣传吸引更多的客户群体，对内苦练内功提高产品技术竞争力，行业正在经历从“有”到“优”的技术升级。行业正在经历这个技术升级的历史阶段，还谈不上结论，只能一块儿来聊聊趋势及预判。本系列专题的关注点是容器隔离技术，因此先不聊商业拓展和容器编排而聚焦于容器引擎技术发展趋势。到如今为止，咱们大致上能够把容器引擎技术划分为两代：

1. Container on VM。也就是按照分层设计思路，经过 IaaS + PaaS 的架构构建容器服务，这个是商用探索阶段的典型架构。基于各大云厂商成熟的 IaaS 基础设施生产虚拟机，在虚拟机里面部署容器服务组件。这种架构采用的是 lift and shift 策略，把容器服务的运维责任从用户转移到云厂商。采用和用户相同的软件组件，只是转移运维责任，有利于引导客户逐步上云、接受云原生思惟。可是这个时期云厂商提供的服务是单纯的运维托管，相对用户自建容器服务并无太明显的技术优点，甚至受多租户隔离的限制部分使用体验还不如用户自建容器服务。
2. Container with hardware virtualization。若是沿用 Container on VM 的分层设计架构，云厂商很难构建独有的技术优点。对于 Serverless 容器实例服务，服务交付平面已经从 IaaS 的硬件接口上移到 OS Syscall，因此不要遵循 VM + 容器的分层设计思路。咱们须要从需求本源出发，容器服务须要高性能、强隔离、够安全和低成本的容器引擎。当前行业研发热点之一就是如何构建这样一个容器引擎，具体技术思路请留意后续系列文章。

小结

总结来看，容器服务生态大概经历了四个阶段，分别解决或试图解决不一样的问题：

1. 技术萌芽期：解决了容器运行环境的隔离问题
2. 技术迸发期：解决了软件分发及容器编排问题
3. 商用探索期：确认了容器的商用服务形态
4. 商用拓展期：扩大适用场景和部署规模，经过技术创新提高产品竞争力

闲言碎语

聊了这么多历史，让咱们再来闲聊一下 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 的群众基础依然强大，可是星星之火已经点燃，趋势已然显现，剩下的只是时间问题！

参考文献

• 《Cloud Native and Container Technology Landscape》
• 《A Brief History of Containers: From the 1970s Till Now》
• 《从虚拟化到云原生——容器技术的发展史》
• 《为何说 2019，是属于容器技术的时代？》
• 《阿里巴巴在安全容器上的实践与探索》
• 《安全容器在边缘计算场景下的实践》
• 《展望 2020：传统容器已死，安全容器将成为云原生标配》

课程推荐

去年，CNCF 与 阿里云联合发布了《云原生技术公开课》已经成为了 Kubernetes 开发者的一门“必修课”。
今天，阿里云再次集结多位具备丰富云原生实践经验的技术专家，正式推出《云原生技术实践公开课》。课程内容由浅入深，专一讲解“ 落地实践”。还为学习者打造了真实、可操做的实验场景，方便验证学习成果，也为以后的实践应用打下坚实基础。点击连接查看课程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”