2013 年的后端技术领域，以 Cloud Foundry 为代表的开源 PaaS 项目开始流行。PaaS 项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。 在当时，虚拟机和云计算已经是比较普遍的技术和服务了，那时主流用户的普遍用法，就是租一批 AWS或者 OpenStack 的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。
当然，这个部署过程难免会碰到云端虚拟机和本地环境不一致的问题，而 PaaS 开源项目的出 现，就是当时解决这个问题的一个最佳方案。基于Pass项目，开发者只要执行一条命令就能把本地的应用部署到云上。
Cloud Foundry通过cgroup和namespace机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在沙盒中运行这些应用进程，来实现进程之间的隔离。
Cloud Foundry有一个较大的弊病是一旦用上了 PaaS，开发者就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，就会出现明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端 PaaS 匹配的“脾气”才能够搞定。
正是Cloud Foundry打包的这个弊病给了Docker机会，Docker提供了一种Docker镜像的方式实现应用的打包功能。Docker镜像通过把操作系统、应用依赖的SDK以及用户的应用打包一个镜像文件中，来实现在不同服务器上保证运行时环境的一致性，同时Docker镜像对开发者非常优化，只需要简单的docker build命令即可打包出自己的应用镜像
2015年左右，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理 解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立 基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。
Kubernetes主打容器编排，Kubernetes最大的优势即：从API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes 项目的每一个阶段。
基于Kubernetes的插件机制衍生出了一系列优秀的开源产品，如：isitio（微服务治理）、Operator（有状态应用部署框架）、rook（通过 Kubernetes 的可扩展接口，把 Ceph 这样的重 量级产品封装成了简单易用的容器存储插件）等，反过来这些开源产品也极大的丰富了Kubernetes的生态系统。
