跳转到内容
← 返回核心概念
系统与架构计算机科学 · 操作系统 · 云计算约 14 分钟阅读

虚拟化与容器

Virtualization and Containers

2006 年，亚马逊推出了一项新服务：EC2（Elastic Compute Cloud）。它让用户通过浏览器点几下，就能在几分钟内"租到"一台 Linux 服务器，不再需要购买物理机器。 这件事在技术上依赖一个已经存在了四十年的想法：虚拟化——让一台物理计算机"假扮"成多台，每台互相隔离。AWS 的出现，让这个想法从…

虚拟化容器Docker虚拟机云计算

2006 年，亚马逊推出了一项新服务：EC2（Elastic Compute Cloud）。它让用户通过浏览器点几下，就能在几分钟内"租到"一台 Linux 服务器，不再需要购买物理机器。

这件事在技术上依赖一个已经存在了四十年的想法：虚拟化——让一台物理计算机"假扮"成多台，每台互相隔离。AWS 的出现，让这个想法从企业数据中心走向了整个互联网产业，并催生了"云计算"这一范式。

起源：一个比云计算早四十年的想法

虚拟化不是云时代的发明。它诞生于大型机分时（time-sharing）的年代。

1964 年，IBM 剑桥科学中心（Cambridge Scientific Center）的 Robert Creasy 和 Les Comeau 开始研发 CP-40。1967 年 1 月它投入使用，第一次让每个用户都拥有一台属于自己的、完整的虚拟 System/360。这是"虚拟机"概念的源头。

紧接着的 CP-67 运行在 IBM System/360 Model 67 上，1967 年 4 月投入分时使用。它能在一台物理机上同时支撑数十个用户，每人都以为自己独占一台机器。

1972 年 8 月 2 日，IBM 发布 VM/370，与首批支持虚拟内存的 System/370 大型机同时推出。VM/370 把"一台机器假扮成多台"做成了成熟产品，其血脉至今仍存活在 IBM 的 z/VM 中。

换句话说：当 2006 年 AWS 让虚拟机变成可以按分钟租用的商品时，这项技术本身已经稳定运行了将近四十年。变的不是原理，而是交付方式与经济规模。

破除误解：虚拟化不只是"模拟器"

很多人见过游戏机模拟器——用软件模拟任天堂 64 的硬件，在 PC 上运行 N64 游戏。这是一种虚拟化，但代价极高：每条指令都需要软件解释，速度只有原机的一个零头。

现代数据中心虚拟化完全不同。它的关键技术叫硬件辅助虚拟化（Hardware-Assisted Virtualization）：Intel 在 2005 年（VT-x）、AMD 在 2006 年（AMD-V）分别在 CPU 中加入了专用指令集，让"客户机"（Guest）的大多数指令可以在物理 CPU 上直接执行，只有少数需要特权的操作才陷入（trap）到监视器层（Hypervisor）。

结果：现代虚拟机的性能损失通常只有 2-5%，几乎感觉不到。

为什么 x86 一度"无法虚拟化"

要让虚拟机高效运行，传统做法叫"陷入并模拟"（trap-and-emulate）：客户机的普通指令直接在 CPU 上跑，遇到会影响全局状态的特权指令时，自动"陷入"到 Hypervisor，由它代为处理。

1974 年，Gerald Popek 和 Robert Goldberg 在论文《Formal Requirements for Virtualizable Third Generation Architectures》中把这件事形式化了。他们证明：一个体系结构要能被经典虚拟化，所有"敏感指令"（会读写全局状态的指令）必须是"特权指令"的子集——这样它们才会在客户机里乖乖陷入。

问题来了：x86 不满足这个条件。它有 17 条"敏感但不特权"的指令（例如 popf、sgdt、sldt、smsw），在用户态执行时既不报错也不陷入，而是悄悄返回了错误的结果。Hypervisor 根本拦不住它们。这正是 1990 年代业界普遍认为"x86 无法虚拟化"的原因。

突破来自 VMware。这家公司 1998 年成立，1999 年 5 月 15 日发布第一款产品 VMware Workstation。它绕过硬件限制的办法叫二进制翻译（binary translation）：在客户机内核代码运行前，动态地把那些麻烦指令改写成会陷入的版本，普通指令则原样直跑。x86 第一次被真正虚拟化了。

后来 Intel VT-x（2005）和 AMD-V（2006）从硬件层面让这些敏感指令可以被陷入，二进制翻译逐渐退场。但要破除另一个误解：硬件辅助并非一开始就更快。VMware 工程师 Adams 与 Agesen 在 2006 年的实测论文中发现，第一代硬件虚拟化因为不支持内存管理单元（MMU）的虚拟化、且每次陷入开销很大，在不少负载上反而打不过成熟的二进制翻译。硬件方案的全面胜出，是在后续加入嵌套页表（如 Intel EPT、AMD NPT）等改进之后。

虚拟机的结构

Hypervisor（虚拟机监控器）是虚拟化的核心软件层，负责在多个虚拟机之间分配和管理物理资源：

物理硬件（CPU、RAM、磁盘、网络）
          |
    Hypervisor（类型1或类型2）
    /          |          \
  VM1          VM2         VM3
(Linux)    (Windows)    (FreeBSD)
  |             |             |
应用程序      应用程序       应用程序
```

类型 1（裸金属 Hypervisor）：直接运行在硬件上，没有宿主操作系统。代表：VMware ESXi、Microsoft Hyper-V、Xen。性能更好，用于数据中心。

类型 2（托管 Hypervisor）：运行在普通操作系统上。代表：VirtualBox、VMware Workstation。方便开发测试，有额外开销。

每个虚拟机有完整的操作系统、独立的虚拟磁盘和虚拟网络接口。VM 之间的隔离由 Hypervisor 强制执行——一个 VM 崩溃不影响其他 VM，一个 VM 无法访问另一个 VM 的内存。

三条技术路线：全虚拟化、半虚拟化、硬件辅助

历史上，让客户机跑在 x86 上有三条路：

全虚拟化（full virtualization）：客户机操作系统完全不知道自己在虚拟机里，无需任何改动。早期靠二进制翻译实现（VMware），代价是翻译开销。

半虚拟化（paravirtualization）：换个思路——既然拦截麻烦指令很贵，那就修改客户机操作系统，让它主动通过"超级调用"（hypercall）向 Hypervisor 请求特权操作。剑桥大学的 Xen 在 2003 年 SOSP 论文《Xen and the Art of Virtualization》中提出这一方案，单机可同时托管上百个虚拟机实例。代价是客户机内核必须改造，因此早期难以运行未经修改的 Windows。

硬件辅助虚拟化（hardware-assisted）：把陷入与模拟的能力直接做进 CPU（VT-x / AMD-V）。KVM 是这条路线的代表：由 Avi Kivity 在 Qumranet 公司开发，2007 年 2 月 5 日随 Linux 2.6.20 内核合入主线。它的巧妙之处在于不另写一个庞大的 Hypervisor，而是把 Linux 内核本身变成 Hypervisor——每个虚拟机就是一个普通的 Linux 进程，复用内核已有的调度器与内存管理。

三条路线并非互斥。今天的主流（KVM、现代 Xen、VMware ESXi）都以硬件辅助为基础，并在 I/O 等局部仍保留半虚拟化驱动（如 virtio）以提升性能。

容器：轻量级的"假虚拟机"

2013 年，Docker 让容器技术普及化。

容器解决了一个实际问题：虚拟机虽然隔离性好，但每个 VM 要运行完整的操作系统（内核 + 系统库 + 应用），启动慢（分钟级），占用大量内存（GB 级）。

容器的思路不同：不虚拟化硬件，而是利用 Linux 内核已有的隔离机制，在同一个内核上创造出看起来相互隔离的用户空间：

  • Namespaces（命名空间）：让每个容器以为自己有独立的进程树、网络、文件系统、用户 ID 等。
  • Cgroups（控制组）：限制每个容器能使用的 CPU、内存、I/O 等资源上限。
  • Union File System：让多个容器共享同一套基础文件系统层（镜像），只存储差异，大幅减少磁盘占用。
物理硬件
    |
Linux 内核（共享）
    |
容器运行时（Docker / containerd）
 /      |      \
容器1  容器2  容器3
(各自隔离的文件系统、进程、网络)
```

关键差异：

特性虚拟机容器
隔离层次硬件级操作系统级
内核每个 VM 独立内核共享宿主内核
启动时间分钟级秒级（甚至毫秒）
镜像大小GB 级MB 级
隔离强度更强（硬件级边界）较弱（内核共享）
典型用途多租户云、安全隔离微服务、CI/CD

Kubernetes：容器的操作系统

一旦服务由数十到数千个容器组成（微服务架构），手动管理每个容器就变得不可能。

Kubernetes（K8s）（Google 2014 年开源）是容器编排系统：它决定把哪些容器运行在哪台机器上，自动重启崩溃的容器，在流量增大时自动扩容，在流量减小时缩容，处理容器之间的网络通信和负载均衡。

Kubernetes 相当于"容器的操作系统"：把一个机器集群抽象成一个统一的计算平台，用户只需声明"我需要 10 个 Nginx 实例"，K8s 负责让这个声明成真。

虚拟化的代价与安全考量

容器逃逸：由于容器共享宿主内核，内核漏洞可能让攻击者突破容器隔离，获得宿主机权限。这是容器安全的核心风险。VM 的内核级隔离使得这类攻击难度更高，但并非不可能（Hypervisor 也有漏洞）。

"噪声邻居"（Noisy Neighbor）问题：共享物理机的多个 VM/容器，如果某个占用了大量 CPU 或网络带宽，会影响同机其他实例——即使 cgroups 有限制，某些资源（L3 缓存、内存带宽）的共享仍难完全隔离。

镜像供应链安全：容器镜像可以从公共仓库（Docker Hub 等）拉取，但这引入了供应链风险——恶意镜像可能包含后门。2020 年代，软件供应链安全成为产业热点，容器镜像签名和验证成为最佳实践要求。

跨域连接

  • 操作系统：能否被高效虚拟化，在指令集设计时就决定了。经典条件要求敏感指令是特权指令的子集，这样它们才会陷入监视器；正文那十几条敏感却不特权的指令使这条路走不通，只能靠二进制翻译或改硬件补救。推论具有一般性——事后补救的方案总是又贵又脆，架构层面的疏漏很难在软件层完全抹平。
  • 投资组合与分散化：统计复用就是分散化。相互独立的负载叠加后，总量的波动按平方根而非线性增长，因此超售的安全边际是可以算出来的。这条数学也给出失效条件：一旦租户的高峰相关起来，比如同一场大促或同一区域故障，分散收益立刻消失。云的价格优势因此依赖负载不相关，而不是依赖规模本身。
  • 公共池塘资源治理：控制组能限制可计量的资源，比如处理器时间与内存字节，却限制不了难以计量的共享资源，比如末级缓存与内存带宽。这解释了噪声邻居问题的分布规律：隔离总是先在最难计量的资源上失效。治理只能作用于可测量的边界，因此提升隔离质量的前提，往往是先把某种资源变得可测。
  • 忒修斯之船：一台被实时迁移到另一台物理机上的虚拟机，还是不是同一台？这不是玄谈：身份由状态连续性还是由物理载体定义，直接决定许可授权、审计留痕与取证如何判定。推论可验证——以硬件指纹绑定的软件授权在虚拟化环境中必然失效，这是技术定义与法律定义分叉的实例，而非实现缺陷。
  • 软件供应链安全：镜像是可执行制品，从公共仓库拉取相当于在生产环境里运行陌生人打包的整个用户空间，它的信任边界比一个库依赖大得多。推论也随之划清：签名与按摘要部署回答的是「跑的是不是我审过的那一份」，回答不了「我审过的那份是否安全」，这两个问题需要不同的证据。

参考文献

  • Popek, G. & Goldberg, R. Formal Requirements for Virtualizable Third Generation Architectures. CACM 17(7), 1974, pp. 412–421. （虚拟化理论奠基论文）
  • Creasy, R. J. The Origin of the VM/370 Time-Sharing System. IBM Journal of Research and Development 25(5), 1981, pp. 483–490. （IBM 虚拟机的第一手历史）
  • Barham, P. et al. Xen and the Art of Virtualization. SOSP 2003. （半虚拟化奠基论文）
  • Adams, K. & Agesen, O. A Comparison of Software and Hardware Techniques for x86 Virtualization. ASPLOS 2006, pp. 2–13. （VMware 工程师对二进制翻译与硬件辅助的实测对比）

延伸阅读

  • Burns, B. et al. Kubernetes: Up and Running. 3rd ed. O'Reilly, 2022.
  • Anderson, C. Docker. （Docker 官方文档，docs.docker.com）

正文中引用本条 · 1