深入剖析kubernetes系列学习之传奇背景（一）

本博客为个人学习极客时间中张磊课程时所作的笔记，仅作交流，不得作为商用

虚机租赁带来的麻烦

2013年左右，当时的云计算领域的霸主以AWS和OpenStack为代表，主要提供虚拟机租赁服务，用户购买后用脚本或手工方式在机器上部署应用——问题就出在这里，部署过程中云端虚拟机与本地环境不一致带来的问题让程序员们头疼。

惊鸿一瞥的“沙盒”

受尽部署痛苦的程序员们打造了以CloudFoundry为代表的开源PaaS项目，PaaS项目能被大家接纳的原因是其提供了“应用托管”的能力，其核心组件是一套应用的打包和分发机制，客户只需执行“cf push”将应用的可执行文件和启动脚本打包为压缩包并上传到CloudFoundry中存储，CloudFoundry通过调度器为这个应用选择可运行的虚拟机并通知虚机上的Agent下载该应用包并启动。

发现没，虚拟机的管理者从用户本身变为了CloudFoundry，不同于用户管理，CloudFoundry管理的一个虚拟机上会下载多个不同用户的应用，没办法，价值最大化嘛~此时，应用之间的隔离就成了问题。CloudFoundry采用的解决方案是调用操作系统的Cgroups和Namespace机制为每个应用单独创建隔离环境——“沙盒”，在“沙盒”中启动应用——这是PaaS项目最核心的能力。

其实CloudFoundry啥都好，就是打包本地应用的过程令人头疼，本地可以运行的应用需要做很多修改和配置工作才能被打包，这些修改和配置没有经验可以借鉴，很迷~免去了部署的烦恼却引入了打包的痛苦，CloudFoundry没想到的是，这时，一个名为dotCloud的PaaS创业公司看到自己没有力