Cloud Ecosystem Evolution Learning

记录深入剖析Kubernetes专栏里关于云生态演变的历程。

初出茅庐

2013年云计算领域，从盛极一时的OpenStack 到 Cloud Foundry为代表的PaaS项目开启了构建平台服务化的变革，都以为Platform as a Service的时代要来了，直到Docker项目出现。

PaaS特点：提供了一种名叫“应用托管”的能力，核心组件是一套应用的打包和分发机制。在云计算和虚拟机普遍的当时，将应用通过脚本部署到这些机器上。

所以，像Cloud Foundry这种给用户提供了流畅的上云体验，通过一个命令将应用上传给Cloud Foundry，在通过虚拟机运行应用。

虚拟机里通过Linux的Cgroups和Namespace机制创建沙盒环境，进行进程间隔离。沙盒≈容器。

事实上，Docker和Cloud Foundry的容器大部分功能和原理是一样的，而Docker的特点就是：Docker镜像

而镜像解决的问题就是 应用打包 问题，以往的PaaS虽然可以打包，但要想在远程VM上跑起来，仍然需要摸索定制，对不同的编程语言不同的套路。

Docker镜像是直接由一个完整操作系统的所有文件和目录构成的压缩包，所以它带来的是环境一致性。沙盒或容器，只要解压压缩包，就可以运行程序了。

Docker镜像给了PaaS打包来了一次降维打击，通过镜像打包应用所需的整个操作系统，解决了环境问题。

但它并不能代替 PaaS 完成大规模部署应用的职责。

崭露头角

Docker 项目之所以能取得如此高的关注，一方面它解决了应用打包和发布这一困扰运维人员多年的技术难题；另一方面，它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里。

Docker开源战略：坚持把“开发者”群体放在至高无上的位置。 相比PaaS，Docker更完美的捕获了应用开发者。

容器化 取代 PaaS化 成功infrastructure领域关键词。

下一个事件是，Docker发布Swarm。

Docker野心不止仅仅解决打包问题，它们需要定义规则，打造自己的平台，进而盈利。走着走着还是回到了PaaS的路上。

不过此时的PaaS，是以docker容器技术为核心，docker镜像为打包标准，全新的容器化思路。

群雄并起

CoreOS推出自研的rkt容器，通过其他开源项目搭建起一套平台产品。开始与Docker公司竞争容器平台化市场。

Docker推出Swarm提供集群管理功能，它完全使用 Docker 项目原本的容器管理 API 来完成集群管理。很方便，用户容易掌握。

对Docker公司来说，下一个事件是，收购Fig，一个容器编排项目。Container Orchestrate

Orchestrate并不是新名词，在云计算中指用户配置一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。

在容器时代，指对 Docker 容器的一系列定义、配置和创建动作的管理。

Fig 就会把这些容器的定义和配置交给 Docker API 按照访问逻辑依次创建，你的一系列容器就都启动了；而容器 A 与 B 之间的关联关系，也会交给 Docker 的 Link 功能通过写入 hosts 文件的方式进行配置。更重要的是，你还可以在 Fig 的配置文件里定义各种容器的副本个数等编排参数，再加上 Swarm 的集群管理能力，一个活脱脱的 PaaS 呼之欲出。

Fig后来改名为Compose。

同期老牌集群管理项目Mesos也推出了自己的PaaS，旨在使用户能够像管理一台机器那样管理一个万级别的物理机集群，并且使用 Docker 容器在这个集群里自由地部署应用。

2014年群雄并起，值得注意的是Google在这年发布了Kubernetes，在一次改变了容器市场格局。

尘埃落定

Docker公司不失时机的推出Docker Compose、Swarm 和 Machine“三件套”，在重新定义 PaaS 的方向上走出了最关键的一步。2014~2015年，整个容器社区围绕docker各种项目热闹非凡。

然而，Docker公司在docker开源项目上始终有着绝对的话语权，为了商业利益最终 走向远离社区的道路。

2015年，容器领域的其他公司为了削弱Docker公司话语权，由Docker、Google、Redhat、CoreOS等成立了一个中立基金会，共同定义一套容器和镜像的标准和规范。

这个标准和规范是：OCI(Open Container Initiative)。OCI的提出目的：将容器运行时 和 镜像的实现 从Docker项目中剥离出来。 但是，OCI并没有改变Docker项目是容器标准的事实。

对于PaaS层，Docker公司只有Swarm，而Google和RedHat这样的公司都有着深厚的技术积累。

所以，这次Google和RedHat等共同发起了 CNCF (Cloud Native Computing Foundation) 。

这个基金会目的：以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

CNCF为了保证k8s在容器编排的领域的竞争力，应对Docker和Mesos压力。Kubernetes选择的是Borg来应对。它源于Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。Kubernetes以超前的设计理解和Google的号召力迅速构建出了一个与众不同的容器编排与管理生态。

有了Kubernetes，CNCF开始发力围绕k8s的生态，Prometheus、Fluentd、OpenTracing等相应发展起来。

2016年，面对CNCF的竞争，Docker公司的策略是，将Swarm内置到docker中。这种一意孤行的做法带来项目的复杂度和维护成本都是不利的。

而Kubernetes策略，和docker最初发展起来的原因一样，充分以开发者考虑，各种插件机制催生出了各种二次创新工作。

胜败显而易见，所以2017年 Docker公司将容器运行时部分Containerd捐赠给CNCF，接着将Docker项目改名为Moby交给社区维护。

2017年Docker 企业版中内置 Kubernetes 项目，至此容器编排之争结束。

2013~2017，从PaaS 到 docker 到 Kubernetes。Infrastructure领域发生很多变数。

从中可以看出，一个开源项目的成功的根本：以开发者为核心，构建一个相对民主和开放的容器生态。

上面内容总结几点：

• 容器技术的兴起源于PaaS技术的普及
• Docker项目具有里程碑的意义，通过镜像解决了应用打包，这个根本问题
• 容器本身没有价值，有价值的是容器编排。类比电力和电器。