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

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

虚机租赁带来的麻烦

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

惊鸿一瞥的“沙盒”

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

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

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

呼风唤雨的Docker

Docker的出现被认为完美解决了CloudFoundry的打包问题——依靠Docker镜像，而这也是Docker的容器与“沙盒”的主要功能区别，可以说，Docker镜像是直接由一个完整操作系统的所有文件和目录组成——即包含这个应用运行所需要的所有依赖，所以镜像压缩包中的内容与用户本地开发和测试环境用的操作系统是完全一致的——这是Docker提供的最重要的能力！

以用户为中心

CloudFoundry为什么让大家难受？因为CloudFoundry的用户——每个开发人员在打包的时候都被搞得焦头烂额，没有以用户为中心的下场就是被用户抛弃。

Docker的出现让服务器端（Linux内核开发、后端开发、运维）的幕后英雄走到前台，Docker的传播离不开后端技术人员的推崇。Docker把一个纯后端的技术概念通过非常友好的设计与封装，交到最广大的开发者（用户）群体手中——每一个开发者，都对如何把自己的代码打包为随处可以运行的Docker镜像充满好奇，你看，Docker与开发者的关系变得亲密，加上PaaS概念的深入人心，Docker不火都不行。一时间，“容器化”取代“PaaS”化成为基础设施领域最热门的话题。一个以“容器”为中心的、全新的云计算市场展现在面前。

野心膨胀的“Docker”

标题的Docker指的是之前提到的dotCloud公司，他们见Docker已经受到技术人员欢迎与追逐，把自己的公司改名为“Docker”，这下大家有点不舒服了，Docker在大家印象里就是开源项目的名字，咋还突然变成你一个公司名了，还被注册商标，以后用这个还可能担负法律风险。为什么这么做呢？——答案就是“为了生意”。Docker概念和技术都是好的，唯一还没有做好的就是“如何让开发者把应用部署在Docker项目上？”哈，其实说白了，容器本身是没有价值的，有价值的是容器编排，这也是商业化的主战场——Docker要跟之前的PaaS抢蛋糕啦，但是单纯一个Docker容器肯定没办法做到，于是，Docker（dotCloud）公司在2014年推出了Swarm项目——一个容器编排工具，这也让Docker公司的平台化野心暴露出来。

八仙过海，各显神通

2014年前后，随着Docker的崛起，各个公司大显神通，都想在容器平台化领域抢占市场，话不多说，感觉我也说不清楚，还是用一张图来归纳一下大致情况吧~

想必看完这张图你就能明白当时战况有多激烈~

人怕出名猪怕壮

所谓“人怕出名猪怕壮”，Docker公司商业化战略触动了云计算领域大佬的蛋糕，作为Docker公司的CTO，具有理想主义情怀的Solomon Hykes拒绝了微软的天价收购，他想以一己之力成为云计算领域的绝对权威，体现在实际行动中就是Docker公司在发展项目过程中一次次拒绝了大佬们合作的意向。可惜，Docker公司只是一家创业型公司，要和CoreOS、RedHat乃至谷歌微软抗衡，无异于痴人说梦。

刀光剑影、尘埃落定

Google公司推出了kubernetes项目，被Docker压制的很尴尬的RedHat与CoreOS马上站队Google，事实证明他们的选择是对的。我梳理了一下Google与Docker公司的交锋大事记，如下图所示：

不再赘述上图过程。其实在kubernetes刚推出的时候，就没有与现有选手正面刚，因为Swarm主打与Docker无缝集成，Mesos擅长大规模集群的调度管理，而kubernetes项目很多特性来自于Google内部的Borg系统，具备强大的编排能力，使得kubernetes项目能够与Swarm与Mesos竞争。有了竞争的资本，接下来就是把kubernetes的思想通过技术手段在开源社区落地，而这项任务就由真正理解开源社区运作和项目研发真谛的RedHat公司完成，在Docker公司招架不住选择放弃Swarm并在Docker内部置入编排功能时，kubernetes项目选择开放更多接口，而这一以开发者为中心的措施彻底奠定了胜局。RedHat与Google的联盟保证了其在kubernetes项目上的影响力，也开启了容器编排领域“三足鼎立”的局面。

最终，Docker公司CTO离职，kubernetes成为容器编排的主流，pod等特性深入人心，容器领域的纷争尘埃落定。

（背景介绍完结）

下篇深入剖析kubernetes系列学习之何为容器（二）