Kubernetes学习笔记（0）前言

前言

2013年，当时的云计算技术中，大部分都以 PaaS 技术为主，而其中的 Cloud Foundry 是业界第一个开源的PaaS云平台，它的客户包括百度、京东、华为、IBM
等众多技术公司。

当时研发了 Docker 的公司做出了这样一个决定：开源自己的容器项目 Docker。

然而这个决定在当时根本没人在乎。容器这个概念也不是 该公司发明的。

PaaS 被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。

备注：说到 PaaS，就提一下 SaaS。SaaS利用互联网向用户提供应用程序， 大多数SaaS应用程序直接通过Web浏览器运行，不需要在客户端进行任何下载或安装。

在当时，虚拟机和云计算已经是比较普遍的技术和服务了，那时主流用户的普遍用法，就是租一批 AWS 或者 OpenStack 的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。

这个部署过程难免会碰到云端虚拟机和本地环境不一致的问题，所以当时的云计算服务，比的就是谁能更好地模拟本地服务器环境。

像 Cloud Foundry 这样的 PaaS 项目，最核心的组件就是一套应用的打包和分发机制。 Cloud Foundry 为每种主流编程语言都定义了一种打包格式，然后把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上 Cloud Foundry 的存储中。接着，Cloud Foundry 会通过调度器选择一个可以运行这个应用的虚拟机，然后通知这个机器上的 Agent 把应用压缩包下载下来启动。

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

而 Docker 项目，实际上跟 Cloud Foundry 的容器并没有太大不同，Docker 实际上只是一个同样使用 Cgroups 和 Namespace 实现的“沙盒”而已，没有什么特别的黑科技。

然而在很短的时间内，Docker 项目因为一个小小的创新：Docker 镜像这个功能，就迅速的发展崛起并打败了 Cloud Foundry 以及所有的 PaaS 项目。

之前介绍过，PaaS 之所以能够帮助用户大规模部署应用到集群里，是因为它提供了一套应用打包的功能。可就是这个打包功能，却成了 PaaS 日后不断遭到用户诟病的一个“软肋”。

出现这个问题的根本原因是，一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。

这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错才能够搞定本地应用和远端 PaaS 的匹配。

Docker 镜像解决的就是 ‘打包’ 这个根本性的问题。

Docker 镜像其实就是一个压缩包。但是这个压缩包里的内容，比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。

实际上，大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容和本地开发和测试环境用的操作系统是完全一样的。

假设应用在本地运行时能看到的环境是 CentOS 7.2 操作系统的所有文件和目录，那么只要用 CentOS 7.2 的 ISO 做一个压缩包，再把应用可执行文件也压缩进去，那么无论在哪里解压这个压缩包，都可以得到和本地测试时一样的环境，也就是本地环境和云端环境或者正式环境高度一致。

Docker镜像的这种设计思想，正好符合了 Docker 官网的那句话：build and share any application, anywhere，意思是 一次构建，处处运行。