本篇文章参考：
1、深入剖析 Kubernetes (geekbang.org)
2、Docker基础技术：Linux Namespace（下） | 酷 壳 - CoolShell
1. PaaS 引领潮流
从容器技术的诞生距今已有将近十年的时间了，在这十年的时间里，容器技术已然成为了最受欢迎、最令人追捧的服务器端技术
把时间调回到 2013 年，让我们来一起追溯一下容器技术的前世今生
2013年的后端技术领域，已经许久没有出现过令人们兴奋的技术了。曾经被寄予厚望的云计算领域，也只不过是从一堆虚无缥缈的概念变成了实实在在的虚拟机
在当时，以 Cloud Foundry 为代表的开源 PaaS 项目，成为了当时云计算技术中的一股清流。
Cloud Foundry 开启了以开源 PaaS 为核心构建平台层服务能力的变革，Paas（Platform as a Service）翻译过来就是平台即服务，Pass 提供了一种所谓的应用托管能力
在 Paas 还未开始之前，虚拟机和云计算是比较普遍的技术和服务了，那时候主流的做法就是租一批虚拟机，然后像管理物理机一样，使用脚本或者手动在上面部署应用
这种做法的好处就是省去了大量精力和成本去搭建机房、购买物理机、组建网络等等，对物理机的管理和维护不再需要用户去完成
但是这时候问题出现了，用户难免会碰到云端的虚拟机会和自己本地环境不一致，所以当时的 云计算 服务提供厂商竞争的就是谁能够更好的模拟本地服务器环境，给用户带来更好的”上云“体验
而 Paas 的出现，就提供了一个很好的解决方案
举个例子，用户租好虚拟机之后，需要在上面部署一个 Cloud Foundry 项目，然后只需要执行一条命令就能把本地的应用部署到虚拟机上
cf push "我的应用"是不是很神奇？
像 Cloud Foundry 这样的 PaaS 项目，最核心的组件就是一套应用的打包和分发机制
Cloud Foundry 为每种主流编程语言都定义了一种打包格式，而 ”cf push“ 的作用基本等同于用户把应用的可执行文件和启动脚本装进一个压缩包内，然后上传到云上的 Cloud Foundry 中
接着，Cloud Foundry 会通过调度器选择一个最适合的虚拟机并通知这台虚拟机上的 agent 把应用压缩包下载安装
关键点在于，一台虚拟机上不可能只跑一个应用，真实情况是一台虚拟机会跑很多个来自不同用户的应用，Cloud Foundry 会通过操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作”沙盒“的隔离环境，然后在不同的”沙盒“里启动不同的应用
这就使得每个用户的应用在虚拟机里互不干涉的运行，把每台虚拟机的性能使用到极限，这正是PaaS 项目最核心的能力。 而这些 Cloud Foundry 用来运行应用的隔离环境，或者说“沙盒”，就是所谓的“容器”
而当时所有的云计算从业者都一致认为：PaaS 的时代就要来了！
2. Docker 弯道超车
他们的想法没有错，前提是一个叫 Docker 的开源项目没有突然冒出来的话
实际上 Docker 跟 Cloud Foundry 的容器没有太大区别，Cloud Foundry 的首席产品经理 James Bayer 就在社区里做了一次详细对比，告诉用户 Docker 实际上只是一个同样使用 Cgroups 和 Namespace 实现的“沙盒”而已，没有什么特别的黑科技，也不需要特别关注
然而令 James Bayer 没有想到的是，短短几个月 Docker 就迅速崛起了，崛起速度如此之快，快到 Cloud Foundry 以及所有的 PaaS 社区还没来得及成为它的竞争对手，就直接被宣告出局了！
用现在的话来描述，这简直就是”降维打击“啊
事实上，当时还名叫 dotCloud 的 Docker 公司，也是这股 PaaS 热潮中的一份子，只不过相较于其他公司，dotCloud 公司实在是太微不足道了，而它的主打产品由于跟主流的 Cloud Foundry 社区脱节，长期以来也无人问津。
眼看就要被如火如荼的 PaaS 风潮抛弃，dotCloud 公司却做出了这样一个决定：开源自己的容器项目 Docker
Docker 能够迅速崛起的原因不是与 Cloud Foundry 大同小异的容器技术，而是——Docker 镜像
前面提到过，Paas 之所以能够帮助用户将大规模应用部署到云上，是因为它提供了一种应用打包功能，可是成也如此，败也如此
一旦用户用上了 Paas ，就必须为每种编程语言，每种框架甚至每个版本的应用去维护一个打好的包，首先是管理成本上去了
其次用户们发现，自己在本地运行得好好的应用，需要做很多修改和配置的工作才能在 Paas 平台上运行起来
结局就是，“cf push”确实是能一键部署了，但是为了实现这个一键部署，用户为每个应用打包的工作可谓一波三折，费尽心机
而 Docker 镜像的出现，恰好解决了打包这个根本问题
所谓 Docker 镜像，其实就是一个压缩包，但这个压缩包比 Paas 压缩包（可执行文件+启动脚本）就要丰富多了，Docker 镜像不但包含了应用的可执行文件和启动脚本，它还包含了应用部署所需要的所有甚至是操作系统！
假设你的应用在本地运行时，能看见的环境是 CentOS 7.2 操作系统的所有文件和目录，那么只要用 CentOS 7.2 的 映像文件 做一个压缩包，再把你的应用可执行文件也压缩进去，那么无论在哪里解压这个压缩包，都可以得到与你本地测试时一样的环境。当然，你的应用也在里面！
这个压缩包（Docker 镜像）包含了完整的操作系统文件和目录，也就是包含了这个应用运行时所需要的所有依赖，所以你可以先用这个压缩包在本地进行开发和测试，完成之后，再把这个压缩包上传到云端运行
在这个过程中你完全不需要担心云端环境和本地环境不一致导致问题，你甚至不需要进行任何的配置或者修改，真正做到了开箱即用
自从 Docker 镜像的横空出世，Paas 里最核心的打包系统一下没了用武之地，依据 Docker 镜像，用户只需要提供好操作系统文件和目录以及应用，然后敲一行命令制作成压缩包
docker build "我的镜像"镜像制作完成之后，用户就可以将其上传到云上，然后再让云上的 Docker 创建一个”容器“来解压这个镜像，再在”容器里面运行自己的应用“
docker run "我的镜像"docker run 创建的“容器”，也是使用 Cgroups 和 Namespace 机制创建出来的隔离环境
对于开发者来说，Docker 项目让他们真正感受到什么叫生产力解放所带来的痛快之后，自然选择了用脚投票，直接宣告 Paas 时代的结束
总结：
- Dcoker 项目给 Paas 项目造成降维打击的原因其实是 Docker 提供了一种非常便利的打包机制
- 这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程
随着 Docker 被大范围使用，Paas 的定义逐渐演变成了一套以 Docker 容器技术为核心，全新的”容器化“思维
后来为了与 Docker 公司的容器编排项目——swarm 进行竞争，Google、Redhat等基础设施领域的玩家们组建了 CNCF（Cloud Native Computing Foundation）基金会，开始打造Kuberentes
Kubernetes 很快远远将Swarm项目甩在身后。为了与 Kubernetes 竞争“容器编排”领域，Docker公司甚至放弃了Swarm项目，但最终未能打败 Kubernetes，在 2017 年，Docker 在自己的主打产品 Docker 企业版中内置 Kubernetes 项目，这标志着“编排之争”落地帷幕
直到现在，Docker 和 Kubernetes 依旧是各大公司的首选技术
