像亚马逊网络服务这样的云基础设施提供商销售虚拟机。EC2 的收入预计今年将超过 10 亿美元。那可是大量的虚拟机。

不难理解为什么会有如此大的需求。您可以获得向上或向下扩展的能力、有保障的计算资源、安全隔离和 API 访问权限来配置所有这些，而无需管理物理服务器的任何开销。

但是，您也为大量的、日益可以避免的开销付费，这些开销的形式是为每个虚拟机运行一个完整的操作系统镜像。这种方法已经成为一个不必要的重型解决方案，它旨在解决如何在云中最好地运行应用程序的根本问题。

图 1. 传统的虚拟化和半虚拟化需要每个实例都有一个完整的操作系统镜像。

直到最近，人们还一直认为操作系统虚拟化是为服务器上运行的应用程序提供适当隔离的唯一途径。由于 Linux 内核在管理应用程序之间隔离方面的最新底层改进，这些假设正迅速变得过时。

现在，容器可以作为操作系统级虚拟化的替代方案，在单个主机上运行多个隔离的系统。单个操作系统内的容器效率更高，并且由于这种效率，它们将在云基础设施行业中取代 VM 架构，成为未来的基础。

图 2. 容器可以共享单个操作系统，并且可以选择共享其他二进制文件和库资源。

我们今天购买虚拟机是有充分理由的：容器过去很糟糕，如果它们以任何有用的形式存在的话。“chroot”当然不能（并且仍然不能）满足多租户设计的资源和安全隔离目标。“nice”是一种赢家通吃的调度机制。内核中的“公平”资源调度通常过于公平，在资源饥渴但不重要的进程和资源饥渴但重要的进程之间平均分配资源。内存和文件描述符限制在正常操作和崩溃超出边界的应用程序之间没有梯度。

虚拟机能够在虚拟机监控器中可行地分区和分配资源，而无需依赖内核支持，或者更糟糕的是，单独的硬件。长期以来，虚拟机是 Linux 上为应用程序 A 提供高达 80% 的 CPU 资源和为应用程序 B 提供高达 20% 的资源的唯一方法。类似的划分和共享方案也存在于内存、磁盘块 I/O、网络 I/O 和其他有争议的资源中。

虚拟机的效率也取得了重大飞跃。过去接近模拟的技术已经发展到直接硬件支持内存页映射和其他难以虚拟化的功能。与直接硬件使用相比，我们的 CPU 性能损失仅为几个百分点。

以下是我们目前为 VM 付出的代价

1. 运行一个完全独立的操作系统来获得资源和安全隔离。

2. 等待操作系统启动时启动时间缓慢。

操作系统通常比它托管的实际应用程序消耗更多的内存和磁盘。Rackspace Cloud 最近停止了 256MB 实例，因为它认为它们不实用。然而，如果应用程序不需要与完整的操作系统共享内存，那么 256MB 对于应用程序来说是一个非常实用的尺寸。

至于启动时间慢，许多云基础设施用户保留备用虚拟机以加速配置。虚拟机已将从请求到接收资源的时间窗口缩短到几分钟，但必须保留备用资源表明它仍然太慢或不够可靠。

VM 相当标准化；在一个系统上运行的系统镜像期望与在自己的裸机计算机上运行的系统镜像基本相同。容器在整个行业中不是很标准化。它们非常依赖于操作系统和内核（BSD jails、Solaris Zones、Linux 命名空间/cgroups）。即使在相同的内核和操作系统上，选项范围也可能从单个进程的安全沙箱到几乎完整的系统。

VM 不必运行与主机相同的内核或操作系统，它们通过虚拟化设备（如网卡）和网络协议从主机获得对资源的访问权限。但是，VM 对于主机系统来说相当不透明；虚拟机监控器对块存储和内存中已写入但已释放的内容的洞察力很差。它们通常利用基于硬件/CPU 的工具来隔离其对内存的访问，并且在主机系统上显示为少量虚拟机监控器进程。

容器必须运行与主机相同的内核，但它们可以选择运行完全不同的软件包树或发行版。容器对主机系统来说相当透明。内核以与在主机系统上运行相同的方式管理内存和文件系统访问。容器通过普通的用户空间/IPC 工具从主机获得对资源的访问权限。某些实现甚至支持将套接字从主机传递到标准 UNIX 工具的容器。

VM 也很笨重。它们需要完整的操作系统和系统镜像，例如 EC2 的 AMI。虚拟机监控器为 VM 运行引导过程，甚至经常模拟 BIOS。它们通常在主机系统上显示为少量虚拟机监控器进程。另一方面，容器是轻量级的。可能没有任何持久性文件或状态，并且主机系统通常直接启动容器化应用程序或运行容器友好的 init 守护程序，如 systemd。它们在主机系统上显示为普通进程。

图 3. 虚拟化将配置与硬件部署分离。容器将配置与操作系统部署和启动分离。

与虚拟机相比，容器的开销极低，具有颠覆性。它们的启动速度非常快，许多配置可以根据请求按需启动，从而实现零空闲内存和 CPU 开销。运行 systemd 或 Upstart 来管理其服务的容器具有小于 5MB 的系统内存开销和几乎为零的 CPU 消耗。借助磁盘的写时复制，配置新容器可以在几秒钟内完成。

容器是我们 Pantheon 维护一致系统架构的方式，该架构跨越免费帐户到集群式、高可用性的企业用户。我们管理一个内部容器供应，我们使用 API 进行配置。

我们并非孤军奋战；几乎每个大型 PaaS 系统（包括 Heroku、OpenShift、dotCloud 和 Cloud Foundry）都具有容器基础，用于运行其平台工具。依赖完整虚拟机的 PaaS 提供商的基础设施成本过高，这会转嫁给他们的客户（这在我们市场中最大的竞争对手中就是这种情况）。

体验容器并体验差异的最简单方法是使用现代 Linux 操作系统——无论是在本地、服务器上，甚至是在 VM 上。Dan Walsh 在 Fedora 上提供了一个很棒的教程，另一个教程使用 systemd 的 nspawn 工具，其中包括 UNIX 套接字切换。

虽然 Pantheon 不从事提供原始容器即服务的业务，但我们正在朝着开源技术基础努力。这与 Facebook 和 Yahoo 孵化 Hadoop 的精神相同；它是我们构建我们想要的产品所需的基础的一部分。我们直接作为共同维护者为 systemd 做出贡献，其中大部分将在下一个 Red Hat Enterprise Linux 版本中提供。我们还向上游发送补丁，以实现更好的服务“激活”支持，以便容器可以仅在需要时运行。

我们的目标是，Fedora 和其他主要发行版（如 Ubuntu）的新安装提供开箱即用的标准 API 和命令行工具，用于管理容器、将它们绑定到端口或 IP 地址以及查看资源预留和利用率水平。这种能力应该使其他公司最终能够访问大量的容器主机和风格，就像 Xen 为今天的 IaaS 服务打开了大门一样。

我们将衡量实现此目标进展情况的一种方法是我们的容器主机机器的“纯粹”程度。如果我们只需安装一些软件包和一个证书（或其他 PKI 集成）即可准备好容器主机系统，我们就实现了目标。自由开源软件 (FOSS) 世界将因此变得更强大，并且 Pantheon 也将受益于减少需要维护的代码以及更广泛地采用以容器为中心的计算。

与 Cloud Foundry、OpenShift 或 OpenStack（它们是开源 PaaS 和 LaaS 堆栈）相比，这种 FOSS 贡献也具有优势。Pantheon 通过 systemd 等项目所做的事情重新定义了用户如何在单台机器上管理应用程序和资源。潜在用户的数量——以及由于它是 FOSS，贡献者的数量——比需要多机部署才能有用的工具大几个数量级。在 FOSS 中，让 99% 的价值惠及 99% 的大型现有用户群也更具可持续性。

效率要求未来在裸机硬件上运行容器。虚拟机已经辉煌了十年。