容器技术是今天最为火热的技术话题，也是云计算、大数据全技术栈必须具备的能力。

其实，在计算机技术发展的历史轨迹中，容器拥有一段漫长且传奇的历史。容器与管理程序虚拟化有所不同，管理程序虚拟化通过中间层将一台或者多台独立的机器虚拟运行与物理硬件之上，而容器则是直接运行在操作系统内核之上的用户空间。因此，容器虚拟化也被称为“操作系统级虚拟化”，容器技术可以让多个独立的用户空间运行在同一台宿主机上。

说起容器技术的发展，我们必须将时间倒带至1979年。那是虚拟化容器技术（virtualized container）的历史，在贝尔实验室（ Bell Laboratories 正在为 Unix V7 （Version 7 Unix）操作系统的发布进行最后的开发和测试工作。那个时候的Unix 操作系统还是贝尔实验室的内部项目，而运行 Unix 的机器则是长得像音响一样的、名叫 PDP 系列的巨型盒子。在那个“软件危机（The Software Crisis）”横行的末期，开发和维护 Unix 这样一套操作系统项目，即使对贝尔实验室来说也绝非易事。

而在 Unix V7 的开发过程中，系统级别软件构建（Build）和测试（Test）的效率其实是其中一个最为棘手的难题。这里的原因也容易理解：当一个系统软件编译和安装完成后，整个测试环境其实就被“污染”了。如果要进行下一次构建、安装和测试，就必须重新搭建和配置整改测试环境。所以，贝尔实验室的聪明脑袋们开始构思一种在现有操作系统环境下“隔离”出一个可供软件进行构建和测试的环境。通过简单的执行一些指令，就改变一个程序的“视图”，让它把当前目录当做自己的根目录。有了这个能力，开发者实际上就间接拥有了应用基础设施“快速销毁和重现”的能力，而不需要在环境搭好之后进入到环境里去进行应用所需的依赖安装和配置。于是，一个叫做 chroot（Change Root）的系统调用就此诞生了。

Chroot 的诞生第一次为世人打开了“进程隔离”的大门。后来Unix chroot一致延续到2000年，同属 Unix 家族的 FreeBSD 操作系统发布了"jail"命令，FreeBSD Jails 把”隔离“这个概念扩展到了进程的完整视图，隔离出了独立进程环境和用户体系，真正实现了进程的沙箱化。而这里的关键在于，这种沙箱的实现，依靠的是操作系统级别的隔离与限制能力而非硬件虚拟化技术。

随后的几年里，紧接着又出现了 Oracle Solaris Containers（Solaris 平台），但无论是FreeBSD Jails还是Solaris基于分区的操作系统实例，都没有能在更广泛的软件开发和交付场景中扮演到更重要的角色，因为当时“云”的概念尚未普及，始终被局限在了小众而有限的世界里。

很快的，OpenVZ问世了，OpenVZ是基于Linux平台的操作系统级服务器虚拟化解决方案。它采用了Swsoft公司的Virtuozzo虚拟化服务器软件产品的内核，可以在单个物理服务器上创建多个隔离的虚拟专用服务器并以最大效率共享硬件和管理资源。每个VPS的运行和独立服务器完全一致，因其自身的用户、应用程序都可以独立重启，可以说是典型的基于Linux内核的虚拟化系统。

后来，我们要将关键时间点锁定在2007年。当时谷歌提出了cgroups的概念，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu,memory,IO等等）的机制。最初由google的工程师提出，后来被整合进Linux内核。Cgroups也是LXC为实现虚拟化所使用的资源管理手段，可以说没有cgroups就没有后来的LXC。

迄今为止，LXC仍然是Linux平台的核心虚拟化技术，它可以提供轻量级的虚拟化，以便隔离进程和资源。而且不需要提供指令解释机制以及全虚拟化的其他复杂性。LXC有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。与传统虚拟化技术相比，它与宿主机使用同一个内核，性能损耗小。而且不需要指令级模拟和编译，容器可以在CPU核心的本地运行指令，更不需要任何专门的解释机制，避免了准虚拟化和系统调用替换中的复杂性。最重要的是它很“轻”。Linux Container提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制。Linux Container有点像chroot，提供了一个拥有自己进程和网络空间的虚拟环境，但又有别于虚拟机，因为lxc是一种操作系统层次上的资源的虚拟化。

容器技术改写了软件交付的发展历程，如果不是亲历者的话，我们很难想象 PaaS 乃至云计算产业的发展，会如何因为 2013 年一个创业公司开源项目的发布而被彻底改变。但这件事情本身，确实是过去 5 年间整个云计算产业变革的真实缩影，这就是Docker的问世。Docker 项目的发布，以及它与 PaaS 的关系，想必我们已经无需在做赘述。一个“降维打击”，就足以给当初业界的争论不休画上一个干净利落的句号。早期Docker 项目发布时，Docker自身无非也是LXC的使用者，它创建和使用应用容器的逻辑跟Warden没有本质不同。不过，我们现在也知道，真正让 PaaS 项目无所适从的是 Docker 项目最厉害的杀手锏：容器镜像。Docker 项目通过容器镜像，直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统也打包了进去。这种思路，可算是解决了困扰 PaaS 用户已久的一致性问题，制作一个“一次发布、随处运行”的 Docker 镜像的意义，一下子就比制作一个连开发和测试环境都无法统一的 Buildpack 高明了太多。因此，Docker项目实际上解决的是一个更高维度的问题——即：软件究竟应该通过什么样的方式进行快速交付。

我们发现，无论是沙箱还是容器，实际上技术落地可能是一个工具，然而实际解决的却是一系列应用问题，比如需求分析、界面原型、构建框架、测试上线、迭代开发、版本部署、功能测试和应用上线等。而这一些列问题切切是今天PaaS平台核心关注的问题。运用容器技术构建PaaS平台，确实更快捷、更简单、更轻便。

另一方面，相比于 Docker 体系以“单一容器”为核心的应用定义方式，Kubernetes 项目则提出了一整套容器化设计模式和对应的控制模型，从而明确了如何真正以容器为核心构建能够真正跟开发者对接起来的应用交付和开发范式。而 Docker 公司、Mesosphere 公司 以及 Kubernetes 项目在“应用”这一层上的不同理解和顶层设计，其实就是所谓“编排之争”的核心所在。

说到这里，我们已经回到了 2019 年这个软件交付已经被 Kubernetes 和容器重新定义的时间点。Kubernetes项目一直在做的，其实是在进一步清晰和明确“应用交付”这个亘古不变的话题。

从概念形成到商业演进，容器技术具备典型的PaaS特征。

分析世界讲方案，为您带来精彩的一页。

——垂直领域、专注原创；

——感谢阅读、感谢共鸣。