1.1 初出茅庐

PaaS:

• 应用托管

由于需要在—个虚拟机上启动多个来自不同羽户的应用, CloudFoundry 会调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称为沙盒的隔离环境, 然后在 “沙盒” 中启动这些应用进程. 这样就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。

Docker 镜像:

• 打包功能, 保持本地环境和云端环境高度一致

容器集群管理项目:

• Swarm

1.2 崭露头脚

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

Docker项目从发布之初就全面发力’从技术｀社区｀商业、市场全方位争取到的开发者群体’实际上是为此后将整个生态吸引到自家PaaS上的—个铺垫。只不过那时’PaaS的定义已经全然不是CloudFoundry描述的那样’而是变成了—套以Docker容器为技术核心, 以Docker镜像为打包标准的全新的‘容器化”思路。

1.3 群雄并起

Fig项目之所以广受欢迎’是因为它首次提出了』容器编排”（containerorchestratlon）的概念。其实’
‘编排”在云计算行业不算是新词’它主要是指用户通过某些工具或者配置来完成一组虚拟机以及关联资源的定义｀配置｀创建删除等工作’然后由云计算平台萤照指定逻辑来完成的过程。

虽然不能提供像Swa1m那样的原生DockerAPI’但Mesos社区拥有＿项独特的竞争力:超大规模集群的管理经验。

20l4年注定是＿个神奇的年份°就在这＿年的6月’基础设施领域的翘楚谷歌公司突然发力’正式宣告了Kubemetes项目的诞生。这个项目不仅挽救了当时的CoTeOS和RedHat,还如同当年Docker项目的横空出世一样, 再一次改变了整个容器市场的格局°

1.4 尘埃落定

真正令大多数人不满意的是’Docker公司在Docker开源项目的发展上始终保持着绝对的权威和发言权’并在多个场合用实际行动挑战了其他玩家（比如CoreOS｀RedHat,甚至谷歌和微软）的切身利益°

20l5年6月22日’由Docker公司牵头’CoreOS、谷歌｀RedHat等公司共同宣布’Docker公司将LibcDntalner捐出’并改名为RunC项目’交由—个完全中立的基金会管理’然后以RunC为依据’大家共同制定一套容器和镜像的标准和规范。

谷歌｀RedHat等开源基础设施领域玩家共同牵头成立了—个名为CNCF（CloudNativeComputlngFoundatjon）的基金会。这个基金会的目的其实很容易理解:以Kubemetes项目为基础’建立—个由开源基础设施领域厂商主导的｀按照独立基金会方式运营的平台级社区’来对抗以Docker公司为核心的容器商业生态°

ubemetes项目的基础特性并不是几个工程师突然“拍脑袋”想出来的’而是谷歌公司在容器化基础设施领
域多年来实践经验的沉淀与升华°这正是Kubemetes项目能够从—开始就避免同Swa1m和Mesos社区同质化的重要手段。

• 容器监控事实标准的Prometheus项目

Kubemetes的应对策略则是反其道而行之,开始在整个社区推行‘‘民主化’,架构’即从APl到容器运行时的每—层Kubemetes项目都为开发者暴露了可以扩展的插件机制’鼓励用户通过代码的方式介人Kubemetes项目的每—个阶段°

• Istio 微服务治理
• Operator 有状态应用部署框架
• Rook