容器十年 ——一部软件交付编年史

做者| 张磊，阿里云容器平台高级技术专家，CNCF Ambassador （CNCF 官方大使），Kubernetes 项目资深成员与维护者，曾就任于 Hyper、微软研究院（MSR），如今负责 Kubernetes 技术及上下游相关工做。

2019年，全世界的开发人员都开始习惯用容器测试本身的软件，用容器作线上发布，开始对容器化的软件构建和交付流程习觉得常。全世界的架构师们都在对“云原生”侃侃而谈，描绘多云时代的应用治理方式，不经意间就把 “sidecar” 这种容器组织方式当作了默认选项。在“云”已经成为了大众基础设施的今天，咱们已经习惯了把“容器“当作现代软件基础设施的基本依赖。这就像咱们天天打开 Eclipse 编写 Java 代码同样天然。
 
但往回倒数两年， 整个容器生态都还在围着 Docker 公司争得不可开交，看起来彻底没有定数。当时的国内不少公有云厂商，甚至都没有正式的 Kubernetes 服务。在那个时候，要依托容器技术在云上托管完整的软件生命周期，能够说是至关前沿的探索。谁能想到短短两年以后，容器这个站在巨人肩膀上的设计，就真的成为技术人员平常工做的一部分呢？
 
伴随着容器技术普及到“千家万户”，咱们在这两年期间所经历的，是现代软件交付形式的一次重要变革。

源起：属于 Jails 们的时代

虚拟化容器技术（virtualized container）的历史，其实能够一直追溯上世纪 70 年代末。时间回到 1979 年，贝尔实验室（ Bell Laboratories 正在为 Unix V7 （Version 7 Unix）操做系统的发布进行最后的开发和测试工做。

Ken Thompson(sitting) and Dennis Ritchie at PDP-11 ©wikipedia
 
在那个时候，Unix 操做系统仍是贝尔实验室的内部项目，而运行 Unix 的机器则是长得像音响同样的、名叫 PDP 系列的巨型盒子。在那个“软件危机（The Software Crisis）”横行的末期，开发和维护 Unix 这样一套操做系统项目，即便对贝尔实验室来讲也绝非易事。更况且，那里的程序员们还得一边开发 Unix ，一边开发 C 语言自己呢。
 
而在 Unix V7 的开发过程当中，系统级别软件构建（Build）和测试（Test）的效率实际上是其中一个最为棘手的难题。这里的缘由也容易理解：当一个系统软件编译和安装完成后，整个测试环境其实就被“污染”了。若是要进行下一次构建、安装和测试，就必须从新搭建和配置整改测试环境。在有云计算能力的今天，咱们或许能够经过虚拟机等方法来完整的复现一个集群。但在那个一块 64K 的内存条要卖 419 美圆的年代，“快速销毁和重建基础设施”的想法仍是有点“科幻”了。
 
因此，贝尔实验室的聪明脑壳们开始构思一种在现有操做系统环境下“隔离”出一个可供软件进行构建和测试的环境。更确切的说，就是我可否简单的执行一些指令，就改变一个程序的“视图”，让它把当前目录当作本身的根目录呢？这样，我每次只要在当前目录里放置一个完整操做系统文件系统部分，该软件运行所需的全部依赖就完备了。
 
更为重要的是，有了这个能力，开发者实际上就间接拥有了应用基础设施“快速销毁和重现”的能力，而不须要在环境搭好以后进入到环境里去进行应用所需的依赖安装和配置。这固然是由于，如今个人整个软件运行的依赖，是以一个操做系统文件目录的形式事先准备好的，而开发者只须要构建和测试应用的时候，切换应用“眼中”的根目录到这个文件目录便可。
 
因而，一个叫作 chroot（Change Root）的系统调用就此诞生了。
 
顾名思义，chroot 的做用是“重定向进程及其子进程的根目录到一个文件系统上的新位置”，使得该进程再也看不到也无法接触到这个位置上层的“世界”。因此这个被隔离出来的新环境就有一个很是形象的名字，叫作 Chroot Jail。
 
值得一提的是，这款孕育了 chroot 的 Unix V7 操做系统，成为了贝尔实验室 Unix 内部发行版的绝唱。在这一年底尾， Unix 操做系统正式被 AT&T 公司商业化，并被容许受权给外部使用，自此开启了一代经典操做系统的传奇之旅。
 
而 Chroot 的诞生，也第一次为世人打开了“进程隔离”的大门。
 
伴随着这种机被更普遍的用户接触到， chroot 也逐渐成为了开发测试环境配置和应用依赖管理的一个重要工具。而 “Jail” 这个用来描述进程被隔离环境的概念，也开始激发出这个技术领域更多的灵感。
 
在 2000 年，同属 Unix 家族的 FreeBSD 操做系统发布了"jail"命令，
宣布了 FreeBSD Jails 隔离环境的正式发布。相比于 Chroot Jail，FreeBSD Jails 把”隔离“这个概念扩展到了进程的完整视图，隔离出了独立进程环境和用户体系，并为 Jails 环境分配了独立的 IP 地址。因此确切的说，尽管 chroot 开创了进程环境隔离的思想，但 FreeBSD Jails，其实才真正实现了进程的沙箱化。而这里的关键在于，这种沙箱的实现，依靠的是操做系统级别的隔离与限制能力而非硬件虚拟化技术。

不过，不管是 FreeBSD Jails（Unix 平台），仍是紧接着出现的 Oracle Solaris Containers（Solaris 平台），都没有能在更普遍的软件开发和交付场景中扮演到更重要的角色。在这段属于 Jails 们的时代，进程沙箱技术由于“云”的概念还没有普及，始终被局限在了小众而有限的世界里。

发展：云，与应用容器

事实上，在 Jails 大行其道的这几年间，一样在迅速发展的 Linux 阵营上也陆续出现多个相似的沙箱技术好比 Linux VServer 和 Open VZ（未进入内核主干）。但跟 Jails 的发展路径比较相似，这些沙箱技术最后也都沦为了小众功能。咱们再次看到了，进程沙箱技术的发展过程当中“云”的角色缺失所带来的影响，其实仍是很是巨大的。而既然说到“云”，咱们就不得不提到基础设施领域的翘楚：Google。
 
Google 在云计算背后最核心的基础设施领域的强大影响力，是被业界公认的一个事实，不管是当初震惊世界的三大论文，仍是像 Borg/Omega 等领先业界多年的内部基础设施项目，都在这个领域扮演者重要的启迪者角色。然而，放眼当今的云计算市场， 仅仅比 Google 云计算发布早一年多的 AWS 倒是“云”这个产业毫无争议的领导者。而往往谈到这里的缘由，你们都会提到一个充满了争议的项目：GAE。

GAE 对于中国的某几代技术人员来讲，能够说是一个挥之不去的记忆。然而，即便是这批 GAE 的忠实用户，恐怕也很难理解这个服务居然就是 Google 当年决定用来对抗 AWS 的核心云产品了。事实上，GAE 自己与其说是 PaaS，倒不如说是简化版的 Serverless。在 2008 年，在绝大多数人还彻底不知道云计算为什么物的状况下，这样的产品要想取得成功拿下企业用户，确实有些困难。
 
不过，在这里咱们想要讨论的并非 Google 的云战略，而是为何从技术的角度上，Google 也认为 GAE 这样的应用托管服务就是云计算呢？
 
这里的一个重要缘由可能不少人都了解过，那就是 Google 的基础设施技术栈实际上是一个标准容器技术栈，而不是一个虚拟机技术栈。更为重要的是，在 Google 的这套体系下，得益于 Borg 项目提供的独有的应用编排与管理能力，容器再也不是一个简单的隔离进程的沙箱，而成为了对应用自己的一种封装方式。依托于这种轻量级的应用封装，Google 的基础设施能够说是一个自然以应用为中心的托管架构和编程框架，这也是不少前 Googler 调侃“离开了 Borg 都不知道怎么写代码”的真实含义。这样一种架构和形态，映射到外部的云服务成为 GAE 这样的一个 PaaS/Serverless 产品，也就容易理解了。
 
而 Google 这套容器化基础设施的规模化应用与成熟，能够追溯到 2004~2007 年之间，而这其中一个最为关键的节点，正是一种名叫 Process Container 技术的发布。
 
Process Container 的目的很是直白，它但愿可以像虚拟化技术那样给进程提供操做系统级别的资源限制、优先级控制、资源审计能力和进程控制能力，这与前面提到的沙箱技术的目标实际上是一致的。这种能力，是前面提到的 Google 内部基础设施得以实现的基本诉求和基础依赖，同时也成为了 Google 眼中“容器”技术的雏形。带着这样的设思路，Process Container 在 2006 年由 Google 的工程师正式推出后，第二年就进入了 Linux 内核主干。
 
不过，因为 Container 这个术语在 Linux 内核中另有它用，Process Container 在 Linux 中被正式更名叫做：Cgroups。Cgroups 技术的出现和成熟，标志在 Linux 阵营中“容器”的概念开始被从新审视和实现。更重要的是，这一次“容器”这个概念的倡导者变成了 Google：一个正在大规模使用容器技术定义世界级基础设施的开拓者。
 
在 2008 年，经过将 Cgroups 的资源管理能力和 Linux Namespace 的视图隔离能力组合在一块儿，LXC（Linux Container）这样的完整的容器技术出如今了 Linux 内核当中。尽管 LXC 提供给用户的能力跟前面提到的各类 Jails 以及 OpenVZ 等早期 Linux 沙箱技术是很是类似的，但伴随着 Linux 操做系统开始迅速占领商用服务器市场的契机，LXC 的境遇比前面的这些前辈要好上很多。
 
而更为重要的是，2008 年以后 AWS ，Microsoft 等巨头们持续不断的开始在公有云市场上进行发力，很快就催生出了一个全新的、名叫 PaaS 的新兴产业。
 
老牌云计算厂商在 IaaS 层的先发优点以及这一部分的技术壁垒，使得愈来愈多受到公有云影响的技术厂商以及云计算的后来者，开始思考如何在 IaaS 之上构建新的技术与商业价值，同时避免走入 GAE 当年的歧途。在这样的背景之下，一批以开源和开放为主要特色的平台级项目应运而生，将 “PaaS” 这个本来虚无缥缈的概念第一次实现和落地。这些 PaaS 项目的定位是应用托管服务，而不一样于 GAE 等公有云托管服务 ，这些开放 PaaS 项目但愿构建的则是彻底独立于 IaaS 层的一套应用管理生态，目标是借助 PaaS 离开发者足够近的优点锁定云乃至全部数据中心的更上层入口。这样的定位，实际上就意味着 PaaS 项目必须可以不依赖 IaaS 层虚拟机技术，就可以将用户提交的应用进行封装，而后快速的部署到下层基础设施上。而这其中，开源、中立，同时又轻量、敏捷的 Linux 容器技术，天然就成为了 PaaS 进行托管和部署应用的最佳选择。
 
在 2009 年，VMware 公司在收购了 SpringSource 公司（Spring 框架的创始公司）以后，将 SpringSource 内部的一个 Java PaaS 项目的名字，套在了本身的一个内部 PaaS 头上，而后于 2011 年宣布了这个项目的开源。这个项目的名字，就叫作：Cloud Foundry。2009年，Cloud Foundry 项目的诞生，第一次对 PaaS 的概念完成了清晰而完整的定义。

这其中，“PaaS 项目经过对应用的直接管理、编排和调度让开发者专一于业务逻辑而非基础设施”，以及“PaaS 项目经过容器技术来封装和启动应用”等理念，也第一次出如今云计算产业当中并获得承认。值得一提的是，Cloud Foundry 用来操做和启动容器的项目叫作：Warden，它最开始是一个 LXC 的封装，后来重构成了直接对 Cgroups 以及 Linux Namespace 操做的架构。
 
Cloud Foundry 等 PaaS 项目的逐渐流行，与当初 Google 发布 GAE 的初衷是彻底同样的。说到底，这些服务都认为应用的开发者不该该关注于虚拟机等底层基础设施，而应该专一在编写业务逻辑这件最有价值的事情上。这个理念，在愈来愈多的人得以经过云的普及开始感觉到管理基础设施的复杂性和高成本以后，才变得愈来愈有说服力。在这幅蓝图中，Linux 容器已经跳出了进程沙箱的局限性，开始扮演的“应用容器”的角色。在这个新的舞台上， 容器和应用终于画上了等号，这才最终使得平台层系统可以实现应用的全生命周期托管。
 
按照这个剧本，容器技术以及云计算的发展，理应向着 PaaS 的和以应用为中心的方向继续演进下去。若是不是有一家叫作 Docker 的公司出现的话。

容器：改写的软件交付的历程

若是不是亲历者的话，你很难想象 PaaS 乃至云计算产业的发展，会如何由于 2013 年一个创业公司开源项目的发布而被完全改变。但这件事情自己，确实是过去 5 年间整个云计算产业变革的真实缩影。

 
Docker 项目的发布，以及它与 PaaS 的关系，想必咱们已经无需在作赘述。一个“降维打击”，就足以给当初业界的争论不休画上一个干净利落的句号。
 
咱们都知道， Docker 项目发布时，无非也是 LXC 的一个使用者，它建立和使用应用容器的逻辑跟 Warden 等没有本质不一样。不过，咱们如今也知道，真正让 PaaS 项目无所适从的，是 Docker 项目最厉害的杀手锏：容器镜像。
 
关于如何封装应用，这自己不是开发者所关心的事情，因此 PaaS 项目有着无数的发挥空间。但到这如何定义应用这个问题，就是跟每一位技术人员息息相关了。在那个时候，Cloud Foundry 给出的方法是 Buildpack，它是一个应用可运行文件（好比 WAR 包）的封装，而后在里面内置了 Cloud Foundry 能够识别的启动和中止脚本，以及配置信息。
 
然而，Docker 项目经过容器镜像，直接将一个应用运行所需的完整环境，即：整个操做系统的文件系统也打包了进去。这种思路，可算是解决了困扰 PaaS 用户已久的一致性问题，制做一个“一次发布、随处运行”的 Docker 镜像的意义，一会儿就比制做一个连开发和测试环境都没法统一的 Buildpack 高明了太多。
 
更为重要的是，Docker 项目还在容器镜像的制做上引入了“层”的概念，这种基于“层”（也就是“commit” ) 进行 build，push，update 的思路，显然是借鉴了 Git 的思想。因此这个作法的好处也跟 Github 一模一样：制做 Docker 镜像再也不是一个枯燥而乏味的事情，由于经过 DockerHub 这样的镜像托管仓库，你和你的软件马上就能够参与到全世界软件分发的流程当中。
 
至此，你就应该明白，Docker 项目实际上解决的确实是一个更高维度的问题：软件究竟应该经过什么样的方式进行交付？更重要的是，一旦当软件的交付方式定义的如此清晰而且完备的时候，利用这个定义在去作一个托管软件的平台好比 PaaS，就变得很是简单而明了了。这也是为何 Docker 项目会屡次表示本身只是“站在巨人肩膀上”的根本缘由：没有最近十年 Linux 容器等技术的提出与完善，要经过一个开源项目来定义而且统一软件的交付历程，恐怕如痴人说梦。

云，应用，与云原生

时至今日，容器镜像已经成为了现代软件交付与分发的事实标准。然而， Docker 公司却并无在这个领域取得一样的领导地位。这里的缘由相比你们已经了然于心：在容器技术取得巨大的成功以后，Docker 公司在接下来的“编排之争”中犯下了错误。事实上，Docker 公司凭借“容器镜像”这个巧妙的创新已经成功解决了“应用交付”所面临的最关键的技术问题。但在如何定义和管理应用这个更为上层的问题上，容器技术并非“银弹”。在“应用”这个与开发者息息相关的领域里，历来就少不了复杂性和灵活性的诉求，而容器技术又自然要求应用的“微服务化”和“单一职责化”，这对于绝大多数真实企业用户来讲都是很是困难的。而这部分用户，又恰恰是云计算产业的关键所在。
 
而相比于 Docker 体系以“单一容器”为核心的应用定义方式，Kubernetes 项目则提出了一整套容器化设计模式和对应的控制模型，从而明确了如何真正以容器为核心构建可以真正跟开发者对接起来的应用交付和开发范式。而 Docker 公司、Mesosphere 公司 以及 Kubernetes 项目在“应用”这一层上的不一样理解和顶层设计，其实就是所谓“编排之争”的核心所在。
 
2017 年底，Google 在过去十年编织全世界最早进的容器化基础设施的经验，最终帮助 Kubernetes 项目取获得了关键的领导地位，并将 CNCF 这个以“云原生”为关键词的组织和生态推向了巅峰。
 
而最为有意思的是， Google 公司在 Kubernetes 项目倾其全力注入的“灵魂”，既不是 Borg/Omega 多年来积累下来的大规模调度与资源管理能力，也不是“三大论文”这样让当年业界可望不可即的领先科技。Kubernetes 项目里最能体现 Google 容器理念的设计，是“源自 Borg/Omega 体系的应用编排与管理能力”。
 
咱们知道，Kubernetes 是一个“重 API 层” 的项目，但咱们还应该理解的是，Kubernetes 是一个“以 API 为中心”的项目。围绕着这套声明式 API，Kubernetes 的容器设计模式，控制器模型，以及异常复杂的 apiserver 实现与扩展机制才有了意义。而这些看似繁杂的设计与实现背后，实际上只服务于一个目的，那就是：如何让用户在管理应用的时候能最大程度的发挥容器和云的价值。
 
本着这个目的，Kubernetes 才会把容器进行组合，用 Pod 的概念来模拟进程组的行为。才会坚持用声明式 API 加控制器模型来进行应用编排，用 API 资源对象的建立与更新（PATCH）来驱动整个系统的持续运转。更确切的说，有了 Pod 和容器设计模式，咱们的应用基础设施才可以与应用（而不是容器）进行交互和响应的能力，实现了“云”与“应用”的直接对接。而有了声明式 API，咱们的应用基础而设施才能真正同下层资源、调度、编排、网络、存储等云的细节与逻辑解耦。咱们如今，能够把这些设计称为“云原生的应用管理思想”，这是咱们“让开发者专一于业务逻辑”、“最大程度发挥云的价值”的关键路径。
 
因此说，Kubernetes 项目一直在作的，实际上是在进一步清晰和明确“应用交付”这个亘古不变的话题。只不过，相比于交付一个容器和容器镜像， Kubernetes 项目正在尝试明确的定义云时代“应用”的概念。在这里，应用是一组容器的有机组合，同时也包括了应用运行所需的网络、存储的需求的描述。而像这样一个“描述”应用的 YAML 文件，放在 etcd 里存起来，而后经过控制器模型驱动整个基础设施的状态不断地向用户声明的状态逼近，就是 Kubernetes 的核心工做原理了。

将来：应用交付的革命不会中止

说到这里，咱们已经回到了 2019 年这个软件交付已经被 Kubernetes 和容器从新定义的时间点。
 
在这个时间点上，Kubernetes 项目正在继续尝试将应用的定义、管理和交付推向一个全新的高度。咱们其实已经看到了现有模型的一些问题与不足之处，尤为是声明式 API 如何更好的与用户的体验达成一致。在这个事情上，Kubernetes 项目还有很多路要走，但也在快速前行。
 
咱们也可以看到，整个云计算生态正在尝试从新思考 PaaS 的故事。Google Cloud Next 2019 上发布的 Cloud Run，其实已经间接宣告了 GAE 正凭借 Kubernetes 和 Knative 的标准 API “浴火重生”。而另外一个典型的例子，则是愈来愈多不少应用被更“极端”的抽象成了 Function，以便彻底托管于与基础设施无关的环境（FaaS）中。若是说容器是完整的应用环境封装从而将应用交付的自由交还给开发者，那么 Function 则是剥离了应用与环境的关系，将应用交付的权利交给了 FaaS 平台。咱们不难看到，云计算在向 PaaS 的发展过程当中被 Docker “搅局”以后，又开始带着“容器”这个全新的思路向 “PaaS” 不断收敛。只不过这一次，PaaS 可能会换一个新的名字叫作：Serverless。
 
咱们还可以看到，云的边界正在被技术和开源迅速的抹平。愈来愈多的软件和框架从设计上就再也不会跟某云产生直接绑定。毕竟，你没办法抚平用户对商业竞争担心和焦虑，也不可能阻止愈来愈多的用户把 Kubernetes 部署在全世界的全部云上和数据中内心。咱们经常把云比做“水、电、煤”，并劝诫开发者不该该关心“发电”和“烧煤”的事情。但实际上，开发者不只不关心这些事情，他们恐怕连“水、电、煤”是哪来的都不想知道。在将来的云的世界里，开发者彻底无差异的交付本身的应用到世界任何一个地方，颇有可能会像如今咱们会把电脑插头插在房间里任何一个插孔里那样天然。这也是为何，咱们看到愈来愈多的开发者在讨论“云原生”。
 
咱们没法预见将来，但代码与技术演进的正在告诉咱们这样一个事实：将来的软件必定是生长于云上的。这将会是“软件交付”这个本质问题的不断自我革命的终极走向，也是“云原生”理念的最核心假设。而所谓“云原生”，实际上就是在定义一条可以让应用最大程度利用云的能力、发挥云的价值的最佳路径。在这条路径上，脱离了“应用”这个载体，“云原生”就无从谈起；容器技术，则是将这个理念落地、将软件交付的革命持续进行下去的重要手段之一。
 
而至于 Kubernetes 项目，它的确是整个“云原生”理念落地的核心与关键所在。但更为重要的是，在此次关于“软件”的技术革命中，Kubernetes 并不须要尝试在 PaaS 领域里分到一杯羹：它会成为连通“云”与“应用”的高速公路，以标准、高效的方式将“应用”快速交付到世界上任何一个位置。而这里的交付目的地，既能够是最终用户，也能够是 PaaS/Serverless 从而催生出更加多样化的应用托管生态。“云”的价值，必定会回归到应用自己。

---

 

一块儿进入云原生架构时代

在云的趋势下，愈来愈多的企业开始将业务与技术向“云原生”演进。这个过程当中最为艰难的挑战其实来自于如何将应用和软件向 Kubernetes 体系进行迁移、交付和持续发布。而在此次技术变革的浪潮中，”云原生应用交付“，已经成为了 2019 年云计算市场上最热门的技术关键词之一。
 
阿里巴巴从 2011 年开始经过容器实践云原生技术体系，在整个业界都尚未任何范例可供参考的大背境下，逐渐摸索出了一套比肩全球一线技术公司而且服务于整个阿里集团的容器化基础设施架构。在这些数以万计的集群管理经验当中，阿里容器平台团队探索并总结了四个让交付更加智能与标准化的方法： Everything on Kubernetes，利用 K8s 来管理一切，包括 K8s 自身； 应用发布回滚策略，按规则进行灰度发布，固然也包括发布 kubelet 自己；将环境进行镜像切分，分为模拟环境和生产环境；而且在监控侧下足功夫，将Kubernetes 变得更白盒化和透明化，及早发现问题、预防问题、解决问题。
 
而近期，阿里云容器平台团队也官宣了两个社区项目：Cloud Native App Hub —— 面向全部开发者的 Kubernetes 应用管理中心，OpenKruise —— 源自全球顶级互联网场景的 Kubernetes 自动化开源项目集。
 
OpenKruise 开源地址：https://github.com/openkruise/kruise
 
Cloud Native App Hub：https://developer.aliyun.com/hub
 
云原生应用中心（Cloud Native App Hub），它首先为国内开发者提供了一个 Helm 应用中国镜像站，方便用户得到云原生应用资源，同时推动标准化应用打包格式，并能够一键将应用交付到K8s 集群当中，大大简化了面向多集群交付云原生应用的步骤；而OpenKruise/Kruise 项目致力于成为“云原生应用自动化引擎”，解决大规模应用场景下的诸多运维痛点。OpenKruise 项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践，从不一样维度解决了 Kubernetes 之上应用的自动化问题，包括部署、升级、弹性扩缩容、QoS 调节、健康检查，迁移修复等等。
 
在接下来，阿里云容器平台团队还会以此为基础，继续同整个生态一块儿推动云原生应用定义、K8s CRD 与 Operator 编程范式、加强型 K8s 自动化插件等一系列可以让云原生应用在规模化多集群场景下实现快速交付、更新和部署等技术的标准化与社区化。
 
咱们期待与您一块儿共建，共同体迎接云原生时代的来临！

 

本文做者：jessie筱姜

原文连接

本文为云栖社区原创内容，未经容许不得转载。