操作系统级虚拟化

玻尔百科

核心要点

操作系统级虚拟化使用内核命名空间（namespaces）和控制组（cgroups）来创建隔离的“容器”环境，这些环境共享同一个宿主机操作系统的内核。
这种共享内核模型通过写时复制（copy-on-write）等机制在内存和存储方面提供了高效率，从而实现了高密度部署。
共享内核也是一个关键的安全风险，需要采用纵深防御的方法，并使用 seccomp 和用户命名空间等工具来缓解漏洞。
容器是现代软件开发和可复现科学的基础，通过将应用程序打包在可移植的环境中解决了依赖性问题。

引言

在隔离、可移植的环境中运行应用程序的理念，已经彻底改变了现代计算，从大型云数据中心到科学家的笔记本电脑，无不如此。但是，如何才能创建这些轻量级的“容器”，使其既能像独立的机器一样运行，又能共享同一个操作系统呢？几十年来，开发者和系统管理员一直在与“依赖地狱”和传统虚拟机的高开销作斗争，寻求一种更高效地隔离和部署软件的方法。操作系统级虚拟化提供了答案，它提供了一种巧妙的共享内核隔离模型。本文将揭示这项强大技术的奥秘。首先，在“原理与机制”一节中，我们将剖析 Linux 内核的核心特性，如命名空间（namespaces）和控制组（cgroups），它们共同营造了隔离的假象。然后，在“应用与跨学科联系”一节中，我们将探讨这些原理如何促成从可复现科学到云安全和效率新模型的各种应用。

原理与机制

要真正领会操作系统级虚拟化的精妙之处，我们必须揭开抽象的层层面纱，审视内核所运用的那些巧妙技巧。其核心在于一个关于创造令人信服的幻象的故事。想象一下，你想在一个隔离的盒子中运行一个程序。构建这个盒子有两种截然不同的方法。

构建盒子的两种方式：虚拟机与容器

一种方式，被称为完全硬件虚拟化，是用软件构建一台完整的虚拟计算机。这个被称为虚拟机监控程序 (hypervisor) 的软件层，模拟了物理机器的硬件——CPU、内存、存储和网卡。在这台模拟计算机内部，你可以安装一个完整、未经修改的操作系统（“客户操作系统”），该系统再运行你的应用程序。从应用程序的角度看，它生活在自己私有的宇宙中。这里的隔离边界是虚拟硬件本身；客户操作系统完全不知道外部世界的存在，就像你身处自己家中时，不会察觉到街上其他房屋的存在一样。这就是虚拟机 (VMs) 的世界。一台虚拟机不仅包含应用程序，还包含一个完整的客户内核，用于管理其虚拟硬件、处理系统调用以及调度自己的进程。

然而，还有另一种更微妙的方式。我们是否可以不构建一台全新的计算机，而只是在现有的计算机内部筑起高墙？这就是操作系统级虚拟化的哲学，也是容器背后的魔法。在这里，只有一个操作系统内核——即宿主机的内核。当你在容器中运行一个应用程序时，它作为标准进程直接在宿主机内核上运行。但内核对它耍了个花招。内核用一组软件边界将该进程包裹起来，制造出它拥有自己私有环境的幻象。隔离边界不再位于硬件层面，而是位于内核自身的系统调用接口层面，该接口受到严密监控，以维持这种幻象。这种方法远为轻量级——你不是在启动一个全新的操作系统，只是在竖起几堵墙。但这些墙有多坚固？它们又是由什么构成的呢？

幻象的艺术：命名空间之旅

构成容器隔离世界的“墙”并非单一的整体，而是一系列内置于 Linux 内核中的、被称为命名空间 (namespaces) 的独立隔离特性。每个命名空间负责虚拟化一种特定的全局系统资源，从而为容器化进程提供该资源的私有视图。让我们来一次这些奇妙幻象的旅行。

幻象1：一个私有的文件世界

文件系统隔离中最古老的技巧是 chroot 系统调用，它改变进程的根目录。这就像告诉一个人他不能离开某个特定的房间。然而，一个聪明的人（或进程）如果能找到方法，例如，在被锁进房间之前就抓住了通往外面的门把手，那么他可能还是能出去。类似地，chroot 监牢存在已知的逃逸向量。一个在 chroot 监牢内拥有 root 权限的进程，仍然共享宿主机的进程空间、网络栈和挂载表，这给了它强大的工具来突破限制。

现代容器使用一种更为健壮的机制：挂载命名空间 (mount namespace)。每个容器都获得自己私有的挂载表。当容器内的进程挂载一个新的文件系统时，该挂载点仅在该容器的挂载命名空间内可见，它不会影响宿主机或任何其他容器。这为文件系统隔离提供了更强的保障，构筑了一堵坚实的墙，而 chroot 只提供了一道脆弱的栅栏。

幻象2：一个私有的进程社会

在任何 Linux 系统中，都有一个特殊的进程，其进程标识符（PID）为 $1$ 。它是所有其他用户空间进程的始祖。如果两个容器中各有一个进程都认为自己是 PID $1$ ，会发生什么？这就是 PID 命名空间的魔力。每个容器都获得自己独立的进程树，从其自己的 PID $1$ 开始。

想象一下，在同一个内核上运行着两个容器， $C_X$ 和 $C_Y$ 。在 $C_X$ 内部，一个进程 $P_X$ 的 PID 是 $123$ 。在 $C_Y$ 内部，一个完全不同的进程 $P_Y$ 的 PID 也是 $123$ 。如果 $P_X$ 试图向 PID $123$ 发送一个终止信号，会发生什么？你可能会预料它会影响到 $P_Y$ 。但事实并非如此。当内核从 $P_X$ 接收到 kill(123, SIGKILL) 系统调用时，它会相对于调用者的 PID 命名空间来执行 PID 查找。在 $P_X$ 的世界里，“PID 123” 指的是其自身容器 $C_X$ 内的一个进程。内核对目标进程的搜索被限制在这个命名空间内，绝不会“看到” $C_Y$ 的兄弟命名空间。因此，信号只在 $C_X$ 内部传递，隔离性得以牢固维持。这是一个深刻的虚拟化例子：进程的名称本身是与上下文相关的。

幻象3：一个私有的网络栈

这个原则也延伸到了网络。每个计算机用户都熟悉 127.0.0.1 这个地址，即 localhost。这是你的计算机用来与自身通信的地址。但在容器内部，“自身”意味着什么？如果同一台宿主机上的两个容器都尝试与 127.0.0.1 通信，它们是在与同一个“自己”对话吗？

答案是否定的，这要归功于网络命名空间 (network namespace)。每个容器都获得自己的虚拟网络栈，配有自己私有的环回接口（lo）。当容器 $C_1$ 中的进程向 127.0.0.1 发送一个数据包时，内核会将该数据包路由到 $C_1$ 的私有环回接口；它永远不会离开容器的命名空间而出现在宿主机或任何其他容器中。该数据包完全在 $C_1$ 的网络栈内被消耗。在容器 $C_2$ 中运行于 127.0.0.1:8080 的服务，对于试图连接同一地址的 $C_1$ 来说是完全不可见的。每个容器都有自己私有的“localhost”，这是一种完美的、作为独立机器的幻象。

命名空间化的原则也适用于其他资源。IPC 命名空间隔离了 System V 进程间通信（Inter-Process Communication）对象，如共享内存段和信号量，防止不同容器中的进程干扰彼此的通信渠道。这些命名空间共同构筑了一套出人意料地坚固的墙。

公平共享：资源控制与效率

隔离至关重要，但这只是故事的一半。如果你有十个容器都在单个 CPU 上运行，你如何防止一个贪婪的容器独占所有的处理时间？这不是一个隔离（看到）的问题，而是一个分配（使用）的问题。Linux 内核的解决方案是一种叫做控制组 (cgroups) 的机制。

Cgroups 允许系统管理员管理和限制一组进程可以消耗的资源——CPU、内存、磁盘 I/O。对于 CPU，这通常由完全公平调度器 (CFS) 来管理。这个想法非常优雅。你可以为每个容器分配一个“权重”或“份额”值 ( $w_i$ )。调度器的目标是确保，在一段时间内，每个容器获得的 CPU 时间份额与其权重成正比。

它是如何实现这一点的呢？想象每个容器都有一个“虚拟运行时间”时钟。当一个容器运行时，它的虚拟时钟以与其权重成反比的速率向前走——权重越高，时钟走得越慢。调度器的简单规则是：总是运行虚拟运行时间最低的容器。这自然地强制了公平性：一个高权重的容器，其虚拟时钟走得慢，因此会更频繁地被选中；而一个低权重容器的时钟会飞速前进，导致它被跳过，直到其他容器赶上。在一个有 $k$ 个容器都想运行的稳定状态下，容器 $i$ 将获得等于 $\frac{w_i}{\sum_{j=1}^{k} w_j}$ 的 CPU 份额。这在不牺牲共享内核效率的前提下，提供了可预测的性能划分。

这种效率是容器的关键优势。因为所有容器共享一个内核并且可以共享通用文件，开销非常低。以内存使用为例。如果你从同一个基础镜像运行 $16$ 个容器，它们最初都将相同的可执行文件和库映射到内存中。内核足够智能，只会将每个文件页的一个物理副本加载到其页面缓存 (page cache) 中，并在这 $16$ 个容器之间共享。这非常高效。

真正的魔法发生在写时复制 (COW)。如果一个容器需要修改一个先前共享的页面，会发生什么？它必须复制整个文件吗？不。内核会介入，只为该单个页面制作一个私有副本，并将其映射到写入容器的地址空间中。其他 $15$ 个容器继续共享原始的、未被触动的页面。每个容器只需为它实际改变的数据支付内存成本。这种“按使用付费”的模型，使得在单个宿主机上运行成百上千个容器成为可能，这是重量级虚拟机无法想象的壮举。

双刃剑：共享世界中的安全

共享内核是高效率的源泉，但它也是一个单点故障。命名空间和 cgroups 是坚固的墙，但它们都由同一个实体构建和执行：宿主机内核。如果容器内的攻击者能找到方法欺骗或破坏内核，他们不仅仅是逃离自己的盒子——他们将接管整个系统。

终极入侵

你可以赋予容器中进程的最危险的权力是什么？是告诉内核该做什么的权力。Linux 内核有一个特性，允许新代码，即内核模块，在其运行时被动态加载。一旦加载，这些代码将以最高级别的权限运行，成为内核自身的一部分。

加载模块的能力由一个名为 CAP_SYS_MODULE 的特殊权限控制。将此能力授予容器是灾难性的危险。这相当于给一个租户权力，让他可以在公寓楼上安装新锁，并给自己一把万能钥匙。容器内的攻击者可以加载一个恶意模块，绕过所有命名空间，禁用所有安全措施，读取任何内存，并完全控制宿主机。我们讨论过的所有美好的隔离都变得毫无意义，因为攻击者不再是受内核规则约束的进程；他们已经成为规则制定者的一部分。

分层防御

由于威胁如此严重，保护容器需要一种“纵深防御”策略。仅仅依靠命名空间是不够的。

最小权限原则：永远不要授予超出绝对必要的权限。CAP_SYS_MODULE 几乎总是应该被禁止。
系统调用过滤：使用像 seccomp 这样的机制，宿主机可以为每个容器提供一份严格的、允许使用的系统调用白名单。如果一个系统调用不在名单上，内核会直接拒绝执行它。这极大地缩小了暴露给容器的内核攻击面。
强制访问控制：像 SELinux 或 AppArmor 这样的工具增加了另一层非自由裁量的规则，即使是特权进程也能被约束。
用户命名空间：这个强大的特性将容器内的 root 用户（UID $0$ ）映射到宿主机上一个非特权的、高编号的用户。因此，即使攻击者在容器内获得了 root 权限，在外部世界里他们也只是一个无名小卒。

这些层次共同构成了一个强大的安全态势，承认任何与共享内核的直接接口都存在固有风险，必须进行细致的管理。

机器中的幽灵

即使有完美的软件隔离，还有一个最后的、微妙的幽灵需要考虑：共享硬件本身。虽然容器可能拥有自己的虚拟网络栈和进程树，但它们最终都在相同的物理 CPU 核心上运行指令，并将其数据存储在相同的物理内存中，而这些内存又由一个共享的末级缓存 (LLC) 进行缓冲。

这个共享缓存为侧信道攻击打开了大门。一个恶意容器（攻击者）无法直接读取受害者容器的数据。但它可以观察受害者内存访问对共享 LLC 产生的副作用。在一次 Prime+Probe 攻击中，攻击者首先用自己的数据填充缓存的特定部分（“Prime”阶段）。然后它等待受害者运行。最后，它测量重新加载自己数据所需的时间（“Probe”阶段）。如果受害者访问的内存映射到缓存的同一部分，攻击者的某些数据就会被驱逐，重新加载就会变慢。如果受害者在该缓存区域不活跃，重新加载就会很快。通过重复这个过程，攻击者可以窥探受害者的内存访问模式，从而可能泄露加密密钥等敏感信息。

这显示了纯软件隔离的深刻局限性。解决方案也必须涉及硬件。防御措施包括使用 Intel 的缓存分配技术 (CAT) 等技术来划分缓存，为每个容器提供一个私有的 LLC 切片，或者将容器固定到多路系统中的不同物理 CPU 插槽上，从而为它们提供物理上分离的 LLC。这些措施在一定程度上重建了硬件隔离，提醒我们，在计算机安全的世界里，抽象永远不能完全脱离其下的物理现实。

应用与跨学科联系

在窥探了操作系统级虚拟化的精巧机制——那些营造孤独幻象的命名空间和担当严格资源会计的控制组——之后，我们现在可以提出最重要的问题：这一切究竟是为了什么？答案与计算本身一样广阔。这种在共享内核的同时隔离进程的简单思想，不仅仅是一种技术上的好奇；它是一项基础性原则，重塑了软件开发、科学发现乃至云计算的经济模式。我们在那些乍一看似乎与神秘的操作系统世界相去甚远的学科中，也能找到它的回响。让我们踏上一段旅程，穿越其中的一些应用，这不只是一份清单，而是对这一强大思想所带来的美丽且常常令人惊讶的后果的探索。

追求完美的数字复制品：驯服复杂性

想象一位计算生物学家正在进行两个不同的项目。第一个项目是复制一项里程碑式的研究，需要一个旧的、特定版本的生物信息学工具 BioAlign v2.7，而该工具又依赖于一个过时的库 libcore-1.1.so。第二个项目是一项前沿分析，需要最新版本 BioAlign v4.1，而它依赖于一个相互冲突的库 libcore-2.3.so。在同一台计算机上，这两个世界无法共存；安装一个库会破坏另一个。这种情景，被亲切地称为“依赖地狱”，曾是程序员和科学家们长期以来令人抓狂的挫败感来源。

操作系统级虚拟化提供了一个惊人简单的解决方案。我们不再试图让这两个交战的生态系统在同一个文件系统上共存，而是将每一个都放入其自己的容器中。一个容器包含 BioAlign v2.7 和 libcore-1.1.so；第二个容器包含 BioAlign v4.1 和 libcore-2.3.so。每个容器都为其应用程序呈现了一个完整、私有的宇宙，拥有自己的文件、自己的库和自己的身份认同感。然而，在这一切之下，它们只是在同一个内核上运行的两个进程，对彼此的存在浑然不觉。冲突消失了。这种简单的封装行为是革命性的。它将一个脆弱、复杂的设置转变为一个健壮且可移植的设置。这位生物学家现在可以将这个容器交给同事，或者在另一台机器上运行它，并保证内部的软件环境保持原始和不变。

这种自包含的“软件胶囊”理念，从单个工具扩展到了可复现科学的巨大挑战。在功能基因组学等领域，一个单一的结果可能是一打不同工具在复杂流水线中链接起来的产物。分子生物学的中心法则告诉我们，我们对 RNA 和蛋白质的测量是动态生物状态的快照；要比较这些快照，我们必须绝对确定我们的计算“相机”和“暗房”——即分析流水线——每一次都是完全相同的。即便是最微小的变动也可能导致不同的结果和有缺陷的生物学结论。

实现这种“按位可复现性”（即相同的原始数据产生完全相同的最终文件，逐位不差）是极其困难的。工具版本的改变、库的细微差异，甚至系统的语言设置都可能改变输出。真正的可复现性需要三管齐下的方法。首先，我们使用容器来创建一个固定的、不可变的执行环境，将每个工具固定到由不可变加密哈希引用的特定版本。其次，我们使用工作流语言将流水线的逻辑定义为一个精确的、版本控制的图，不留任何关于操作顺序的歧义。第三，我们使用元数据标准来严格描述我们的输入数据和参数。这些技术共同创造了一个完整的、可执行的科学结果“数字配方”。通过在不同机器上运行多次测试，并验证每个输出文件都具有完全相同的加密哈希值，我们可以证明我们的分析是真正可复现的,。

这种对完美复制的追求甚至可以向内，应用于我们用来构建软件的工具本身。我们如何能确定我们用来构建程序的编译器本身没有因其构建环境而引入的细微缺陷？利用容器化环境，我们可以进行复杂的实验，如“多样化双重编译”。我们可以在两个略有不同的宿主工具链中构建一个新的编译器，然后使用每个新编译器再次构建自己。如果最终产生的编译器不是按位相同的，就揭示了对宿主环境的隐藏依赖。这使我们能够追查并消除不确定性的来源，从根本上建立我们软件供应链的信任链。

效率的经济学：以少成多

容器的优雅不仅在于其隔离性，还在于其效率。由于它们共享宿主内核，与完全虚拟机相比，它们在内存和存储方面的开销极低。这带来了深远的经济影响，尤其是在大规模的云数据中心。

考虑一下容器镜像是如何存储的。运行一百个容器，每个都带有自己的操作系统副本，将是极大的浪费。相反，像覆盖文件系统（overlay filesystem）这样的技术采用了一种巧妙的分层策略。一个容器镜像由多个只读层组成，就像一叠透明的薄片。一个基础层可能包含核心操作系统文件。另一层可能添加共享库，最后一层添加应用程序本身。当我们运行一个容器时，一个新的、薄的可写层被放置在顶部。如果一个容器需要修改来自下层的某个文件，一个副本会被制作到其私有的可写层中（一种“写时复制”操作）。

这种设计对效率有一个美妙的后果。如果我们运行一百个共享相同基础层的容器，这些层在磁盘上只存储一次。更好的是，当第一个容器从共享层读取一个文件时，该文件的数据被加载到内核的页面缓存中。当接下来的九十九个容器读取同一个文件时，它们会获得近乎瞬时的缓存命中，直接从内存中得到服务。通过智能地设计我们的镜像以最大化这些共享通用层的大小，我们可以显著减少存储消耗和应用程序启动时间。

这种对效率的追求延伸到了内存本身。内核同页合并（KSM）是一项扫描系统内存，寻找按位完全相同页面的功能。当它找到这些页面时——可能是在十几个运行相同服务的相同容器中——它会将它们合并为单个物理 RAM 页面，并将其标记为写时复制。这可以带来可观的内存节省。然而，这种巧妙的优化也带来了隐藏的代价：它制造了一个安全漏洞。一个恶意容器可以精心构造一个具有特定内容的内存页面，然后计时写入它需要多长时间。快速写入意味着该页面是私有的。缓慢的写入则意味着该页面是共享的，触发了一次耗时的写时复制错误。这种时间差异泄露了信息，允许攻击者推断出共存的容器是否拥有具有该确切内容的内存页面。这提出了一个经典的工程权衡：在资源效率和安全隔离之间的选择。

容器提供的细粒度资源控制也为新的应用打开了大门，例如能量感知调度。现代处理器的功耗不是线性的；它随着利用率超线性增长。利用率分数 $U$ 的功耗 $P(U)$ 可以建模为 $P(U) = P_{\mathrm{idle}} + k U^{\alpha}$ ，其中 $\alpha > 1$ 。这意味着在高利用率下的小幅降低可以产生显著的节能效果。使用控制组，调度器可以执行一种“绿色”策略。它可以识别关键容器并保持其不受影响，同时轻微限制所有非关键容器的 CPU 份额，以将整个服务器保持在特定的功耗上限之下。这使得数据中心能够动态管理其能源足迹，以精确和有针对性的方式平衡性能与功耗。

驰骋前沿：安全与专业化

尽管容器的共享内核模型功能强大，但它也是一把双刃剑。它是其效率的源泉，但也是其最大的潜在弱点。所有容器中的所有进程，无论被命名空间隔离得多好，最终都向同一个、单一的内核发起系统调用。该共享内核中的一个漏洞可能会让恶意进程“逃逸”其容器并危及整个宿主机。这使得容器的安全边界与传统虚拟机（VM）的根本不同——并且可以说更薄。传统虚拟机在虚拟机监控程序的监督下运行自己完整的、独立的内核。

因此，保护容器化环境是一项纵深防御的工作。我们不单独依赖命名空间。我们使用像 seccomp 这样的功能来过滤允许的系统调用列表，从而大幅减少内核的攻击面。我们采用像 SELinux 或 AppArmor 这样的强制访问控制（MAC）系统来执行更严格的规则，限制容器可以访问的文件和网络资源。我们还使用用户命名空间来确保即使进程逃逸，它在宿主机上也只是一个非特权用户，从而限制其可能造成的损害。

容器模型在处理图形处理单元（GPU）等专用硬件时也面临挑战，而这些硬件对于现代机器学习和科学计算至关重要。命名空间不会虚拟化硬件。容器不能简单地“看到”一个虚拟 GPU。相反，访问必须被小心地接入。一个专门的容器运行时，如 NVIDIA 运行时，通过拦截容器的启动过程来工作。它发现宿主机上的 GPU，然后选择性地将必要的设备文件（例如 /dev/nvidia0）在容器的挂载命名空间内变得可见。同时，它配置容器的 cgroup 以授予其访问该特定设备的权限。这是一种精心策划的直通，而非虚拟化，它突显了基础容器模型必须如何扩展以适应高性能计算的复杂需求。

隔离与性能之间的张力推动了一项引人入胜的新技术的发展：微型虚拟机 (microVM)。在无服务器计算或函数即服务（Function-as-a-Service）的世界里，云服务提供商需要运行来自成千上万不同客户的小段代码，这既要求超快的启动速度（低“冷启动延迟”），也要求铁一般的安全性。容器速度快，但在这种高度多租户的环境中，它们的共享内核模型可能成为安全风险。传统虚拟机提供强大的、由硬件强制执行的隔离，但启动速度太慢。

像亚马逊的 Firecracker 这样的微型虚拟机，达成了一种绝妙的折衷。它们是真正的虚拟机，使用硬件虚拟化来提供强大的安全边界。但它们是极端简约的。它们剥离了每一个非必要的虚拟设备——没有传统的 BIOS，没有仿真的显卡，只有一套最精简的半虚拟化网络和块设备。这极大地缩短了启动时间。通过将这种极简主义与快照/恢复技术相结合，一个微型虚拟机可以在毫秒级内启动，接近容器的速度，同时提供虚拟机的安全性。这表明操作系统级虚拟化是隔离技术谱系上的一个点，而“最佳”选择永远是特定问题所要求的具体权衡的函数。

从解决生物学家的依赖难题到保障云的基础安全，操作系统级虚拟化远不止是一种单纯的技术实现。它是一个强大的镜头，通过它我们可以审视计算中的核心挑战——复杂性、效率和安全性——并且是一个可以用来解决这些挑战的多功能工具。