1、物理机时代
在虚拟机出现于业务环境中以前，应用往往部署在物理机器上，但是 无论是 Windows 服务器还是 Linux 服务器都缺乏相应的技术手段保证一台服务器上可以稳定且安全的同时运行多个应用，因此，这样的部署方式存在弊端就是：空闲资源难以得到复用，部署异构系统时需要重新采购物理资源，大量中小容量的机器使得运维成本提升。
在这样的情况下，如何降低基础设施的管理成本便成为急切的需求。
2、VMware 时代
为解决上述问题，VMware 推出了他们的产品————虚拟机，虚拟机的出现使得用户在一台物理机上能够独立运行多个相互隔离的系统，通过对资源的抽象化使得主机资源能够被有效复用，这对于企业IT管理十分有益。
然而，虚拟机同样也会带来一些问题：
大量独立系统的运行会占用许多额外开销，消耗宿主机器资源，资源竞争时可能会严重影响系统响应；
此外，每运行新的虚拟机都需要重新配置一遍环境，和在物理机上的情况基本无异，重复的环境配置操作则会消耗开发和运维人员的工作时间。
此时需求便关注到如何减少虚拟化时的资源损耗，同时还能保证隔离性，以及使应用的上线周期更短，这便引导了容器技术的发展。
3、容器化时代
现代的容器技术起源于 Linux ，其是很多人长期的、持续的贡献产物，自 2000 年开始各家类 Unix操 作系统厂商开始陆续推出容器相关的项目。
2008 年 Google 的 Cgroups 贡献给 Linux kernel 2.6.24 后，创造了LXC（ Linux Containers），实现了多个独立的 Linux 环境（容器）可运行在同一个内核。对于一个完整独立运行环境来说，需要包含三个关键：环境隔离、资源控制和文件系统。在 LXC 中则分别通过 Namespace、Cgroups、rootfs 来实现相应的能力：
Namespace — 环境隔离：LXC 将内核全局资源封装，每个 Namespace 都有一份独立的资源，使得不同的进程在各自 Namespace 内对同一种资源的使用互不干扰，不会影响其他 Namespace 下的资源，实现了进程隔离；
Cgroups - 资源控制：LXC 通过 Cgroups 对资源进行控制，限制和隔离一组进程对系统资源的使用。在 Cgroups 出现之前 OS 只能对一个进程做资源限制，而 Cgroups 可以对进程进行任意分组，如何分组由用户自定义，借此实现对于一个 Namespace 的资源调度管理；
rootfs - 文件系统：rootfs 挂载在容器根目录上，用来为容器进程提供隔离后执行环境的文件系统。rootfs 包含一个操作系统所涉及的文件、配置和目录，在 Linux 操作系统内核启动时，内核会先挂载一个只读的 rootfs，当系统检测其完整性之后，决定是否将其切换到读写模式。
在通过 LXC 构建容器后，一台宿主机能够实现多个相互隔离应用的运行。同时，共享内核使得每个容器又很轻量，解决了运行大量隔离应用时虚拟机资源消耗过重的弊端。
然而，LXC 虽解决了应用隔离的问题，但却只是轻量的容器技术，没有解决各平台软件交付标准不统一的问题，如不同的软件交付工具、应用运行规范不统一、环境依赖复杂等带来的配置开销。这些问题使容器技术的推广依然比较有限，直到 Docker 的出现。
4、Docker 时代
早期 Docker 是基于 LXC 开发，因此 Docker 容器也有着和 LXC 相似的特性，仅需要较少资源便可以启动。但不同于 LXC，Docker除了容器运行，还是一个打包、分发和运行应用程序的平台。Docker 允许将应用和其依赖的运行环境打包在一起，打包好的 “集装箱“（镜像）能够被分发到任何节点上执行，无需再进行配置环境的部署。这样使得 Docker 解决了开发和部署应用时环境配置的问题，规范化了应用交付和部署，降低了部署测试的复杂度以及开发运维的耦合度，极大提升了容器移植的便利性，便于构建自动化的部署交付流程。
Docker 和虚拟机都是资源虚拟化发展的产物，但二者在架构上又有区别：
虚拟机通过 Hypervisor 虚拟化主机硬件资源，然后构建客户机操作系统，由宿主机的管理程序管理；
Docker 直接运行于主机内核，应用在主操作系统的用户空间上执行独立任务，不需要从操作系统开始构建环境，赋予了应用从交付到部署再到运维的独立性。
虚拟机的启动时间可能是分钟级的，而 Docker 容器创建是秒级别。对于硬盘的使用 Docker 一般为 MB 级别，远小于包含操作系统的虚拟机 GB 级磁盘使用量。对于操作系统来说，能支持运行的 Docker 容器数量远多于虚拟机。
Docker 容器技术在快速部署、环境标准化、隔离性方面的优势得到了开发人员普遍认可，但是如果以一个完整 PaaS 平台为标准来衡量这些还不够。首先，Docker 提供了名为 “容器” 的隔离环境，但是面对多容器间有拓扑有关联的场景，Docker还难以应对；其次，虽然容器解决了应用交付规范问题，但难以实现完全应用托管；另外，随着基础设施规模的扩大，开发中心必将分布式化，调度问题就需要解决。
2014 年 7 月 Docker 宣布收购单机容器编排软件 Fig（后来命名为 Docker Compose），并在同年 12 月推出了自己的容器集群编排项目 Docker Swarm。Docker Swarm 成功打造了两方面能力：
多容器编排能力，支持通过 YAML 文件声明多容器应用，并定义容器之间的关系；
分布式调度能力，允许跨集群节点调度容器。
Docker Compose 和 Dockers Swarm 可以基本满足开发人员对于 PaaS 平台的需求，对于Docker向平台化发展的规划具有基石一般的意义。至此，Docker未来的发展似乎很乐观，但是随着Google加入，容器市场的局面发生了重大改变。
5、Kubernetes
2014 年 Google 开源了名为 Kubernetes（简称K8S）的项目，它是由 Google 内部 Borg 项目而开源出来的容器集群管理系统。Kubernetes 继承了 Google 丰富的大规模集群运维的经验和基因，能够提供复杂的、大规模的容器编排管理服务。2015 年 Google 发布了 Kubernetes 第一个商业版本，代表 Kubernetes 进军生产级容器规模管理，也意味着开始与 Docker 竞争 PaaS 平台的未来版图。
Kubernetes 集群由两类节点构成：Master Node 和 Worker Node。Kubernetes 采用声明式的设计，任何操作指令都通过声明式 API 与 Master 通信。Master Node 可响应 API 声明，进行集群管理和容器调度。容器则运行在 Worker Node，Worker 负责响应 Master 指令，执行容器启停等维护操作。
除了紧密的容器关系，一个面向生产的编排系统必然应当支持更多的容器关系，所以 Kubernetes 还提供了 Deployment 无状态多副本关系、StatefulSet 有状态多副本关系、Job 一次性长任务等许多对象以满足多样的编排需求。这些对象的基础调度单元还是 Pod，由控制器 Controller 控制 Pod 对象的状态来实现声明的编排关系。
Kubernetes 使开发人员和工程师拥有了快速处理大型项目所需的管理工具和基础架构。从负载测试或创建过渡环境，到将业务和在线应用程序移至生产环境，Kubernetes 集群都可以对其进行管理。
