部署方式发展史
石器时代
最原始的时代，所有应用部署在物理主机上，要部署Applications，首先需要组网，然后部署存储、购买硬件、安装操作系统、部署数据库、安全组件、运行时环境，最后部署应用，之后还要花大量的时间，在数据库之间做数据同步，不利于多人多地协同的。
云计算时代
后来进入虚拟化部署时代，虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM），虚拟化技术能够更好地利用物理服务器上的资源，每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。但是虚拟化仍然存在环境笨重，耦合度高等缺点。
云原生时代
利用云计算，实现3种服务模式，IaaS(Infrastructure-as-a-Service)、PaaS(Platform-as-a-Service)、SaaS(Software-as-a-Service)。
IaaS阶段，基础服务设施即服务，只需向供应商购买相应的基础设施服务，基础设置包含了网络、虚拟化、操作系统等服务，然后在其上面部署数据库、安全组件、运行时环境、最后部署应用即可。PaaS阶段，平台即服务，平台服务包含了基本的网络、磁盘、操作系统、数据库、运行环境等，只需将应用部署到上面即可。SaaS阶段，软件设施即服务，例如Office，我们不需要经过一小时的安装，只需通过浏览器访问到其服务器端即可完成我们的需求。
Paas
PaaS经过了好几代的更替，最开始的时候是人工的构建方式，比如我向供应商打一个电话，说”我需要一个LAMP的环境，Apache要求2.3版本，PhP要求5.3版本，MySQL需要5.5版本“，那么供应商需要人工或者通过脚本的方式去生成相应的运行平台，然后再将这个地址给我，我远程登陆即可，后来由OpenStack一直发展到以Colud Foundry为代表的开源PaaS项目，成为了当时云计算技术中的一股清流。
PaaS项目被大家接纳的一个主要原因，就是它提供了一种名叫应用托管的能力。之前用户租赁的服务器或者平台服务，用户难免会遇到云端虚拟机和本地环境不一致的问题，所以当时的云计算，比的就是谁能更好地模拟本地服务器环境，能带来更好的“上云”体验。PaaS项目是当时解决这个问题的一个最佳方案。事实上，像Cloud Foundry这样的PaaS项目，最核心的组件就是一套应用的打包和分发机制。Cloud Foundry定义了一种打包方式，将用户的可执行文件和启动脚本打进一个压缩包内，上传至云端，接着，Cloud Foundry会通过调度策略选择一个可以运行这个应用的虚拟机，然后通知这个机器将应用压缩包下载下来并启动。
这时候关键来了，由于需要在一个虚拟机上启动很多个来自不同用户的应用，Cloun Foundry会调用操作系统的Cgroups和Namespace机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在这个“沙盒”中启动这些应用程序。这样，就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。这正式PasS项目最核心的能力。而这些“沙盒“，就是所谓的”容器“。
Docker
在这股PaaS热潮中，当时还名叫dotCloud的Docker公司，也是其中的一份子，长期以来无人问津。眼看就要被如火如荼的PaaS风潮抛弃，dotCloud公司决定开发自己的容器项目Docker。然而，短短几个月，Docker项目就迅速崛起。Docker项目确实与Cloud Foundry的容器在大部分功能和实现原理上都是一样的，可偏偏就是这剩下的一小部分不一样的功能，成了Docker项目接下来”呼风唤雨“的不二法宝。这个功能就是Docker镜像。
Docker镜像从根本上解决了打包这个问题。所谓Docker镜像，其实就是个压缩包。但是这个压缩包里面的内容，比PaaS的应用可执行文件+启停脚本的组合就要丰富多了。实际上，大多数Docker镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。即该镜像不论在哪儿运行，都可以得到和你本地测试时一样的环境。这正式Docker镜像的精髓。
所以，Docker项目给Paas世界带来了“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错“来匹配两种不同运行环境之间差异的痛苦过程。
解决了应用打包这个根本性的问题，同开发者与生俱来的亲密关系，再加上PaaS概念已经深入人心的完美契机，成为Docker这个技术上看似平淡无奇的项目一举走红的重要原因。
Kubernetes
但是容器化也带了一个问题，例如我需要部署一个JavaWeb项目，用到4台物理机，A、B、C、D，A服务器部署Nginx、B、C部署Tomcat、D服务器部署MySQL服务器，他们之间的网络联通通过基本的TCP就可以访问。但是如果一旦容器化之后，例如我在A服务器上部署Docker-Nginx并将容器例如80端口映射到物理机80端口、B、C服务器上部署Docker-Tomcat并将容器例如8080端口映射到物理机8080端口、D服务器上部署MySQL服务器并将端口3306端口映射到物理机3306端口，并且我们一般容器化就是最大化利用资源，一台物理机上会部署多个Docker容器，你会发现仅端口管理就让人头大，更不用说集群的容错恢复等，那么怎么解决这个问题呢？也就是说容器的集群化有没有好的方案呢？有需求就会有产品，这个产品叫资源管理器。
Docker公司也意识到这个问题，在2014年12月的 DockerCon上发布Swarm，之后，大量围绕着Docker项目的网络、存储、监控、CI/CD，甚至UI项目纷纷出台，也涌现出了很多 Rancher、Tutum这样在开源与商业上均取得了巨大成功的创业公司。这令人兴奋的繁荣背后，却浮现出了更多的担忧。很多从业者意识到Docker项目此时已经成为Docker公司一个商业产品，而开源，只是 Docker公司吸引开发者群体的一个重要手段，更重要的是，Docker公司在Docker开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微软）的切身利益。
所以这次，Google、RedHat等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以Kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。
Kubernetes项目，并不是几个工程师突然“拍脑袋”想出来的东西，而是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华,另一方面,kubernetes整个社区推进“民主化”架构，即：从API到容器运行时的每一层，Kubernetes项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到Kubernetes项目的每一个阶段。
Kubernetes项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新工作，比如：
目前热度极高的微服务治理项目Istio；
被广泛采用的有状态应用部署框架Operator；
还有像Rook这样的开源创业项目，它通过Kubernetes的可扩展接口，把Ceph这样的重量级产品封装成了简单易用的容器存储插件。
就这样，在这种鼓励二次创新的整体氛围当中，Kubernetes社区在2016 年之后得到了空前的发展。更重要的是，不同于之前局限于“打包、发布”这样的PaaS化路线，这一次容器社区的繁荣，是一次完全以Kubernetes项目为核心的“百花争鸣”。
– 引用自知乎一起学习k8s