持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第6天，点击查看活动详情
一个“容器”，是个由Linux Namespace、Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境。一个正在运行的Linux容器，可被看做
- 一组联合挂载在 /var/lib/docker/aufs/mnt 上的rootfs，这部分称为“容器镜像”（Container Image），容器的静态视图
- 一个由Namespace+Cgroups构成的隔离环境，这部分为“容器运行时”（Container Runtime），容器的动态视图
作为一名开发者，并不关心容器运行时的差异。因为整个“开发-测试-发布”流程，真正承载容器信息进行传递的，是容器镜像，而非容器运行时。
这重要假设，正是容器技术圈在Docker项目成功后不久，就迅速走向“容器编排”的主要原因：作为云基础设施提供商，只要能将用户提交的Docker镜像容器方式运行，就能成为容器生态图上的一个承载点，从而将整个容器技术栈上的价值，沉淀在这个节点。
更重要的，只要从我这个承载点向Docker镜像制作者和使用者方向回溯，整条路径上的各个服务节点。如CI/CD、监控、安全、网络、存储等，都有我发挥和盈利的余地。 这个逻辑，正是所有云计算提供商如此热衷于容器技术的重要原因：通过容器镜像，它们可以和开发者关联起来。
从一个开发者和单一的容器镜像，到无数开发者和庞大容器集群，容器技术实现从“容器”到“容器云”。 容器从一个小工具，一跃成为云计算主角，而能够定义容器组织和管理规范的“容器编排”技术，坐上了容器技术领域的“头把交椅”。
最具代表性的容器编排工具，当属
- Docker公司的Compose+Swarm组合
- Google与RedHat公司共同主导的Kubernetes项目
Kubernetes项目的理论基础比工程实践走得靠前得多，归功于Google在2015年4月发布的Borg论文。Borg承载Google整个基础设施的核心依赖，位居整个基础设施技术栈的最底层：
这图来自于Google Omega论文的第一作者的博士毕业论文。它描绘了当时Google已经公开发表的整个基础设施栈。在这个图里，你既可以找到MapReduce、BigTable等知名项目，也能看到Borg和它的继任者Omega位于整个技术栈的最底层。所以Borg没有开源。 得益于Docker项目和容器技术的风靡，它以另一种方式与开源社区见面，即Kubernetes。
Kubernetes每个核心特性都脱胎于Borg/Omega系统的设计与经验。在逐渐觉察到Docker技术栈的“稚嫩”和Mesos社区的“老迈”，社区很快明白：Kubernetes项目在Borg体系的指导下，体现出了一种独有的先进与完备性，这些才是一个基础设施领域开源项目的核心价值。
