Soltesz 2007 — 容器：比虚拟机轻一档的隔离方案

是什么

这篇论文给”容器”这个词写下了第一份系统的工程对照：让一台机器假装自己是几十台机器，但所有租户共用一个 Linux 内核。

日常类比：

• 虚拟机像在一栋楼里给每户人家盖独立的房子——每户都有自己的地基、墙、屋顶（独立操作系统）。
• 容器像在一栋大楼里隔出独立公寓——共享地基和承重墙（共享内核），但门、窗、水电表各自独立（命名空间、配额）。

作者实现的系统叫 Linux-VServer，2001 年起以补丁形式给 Linux 内核打增强。论文用它对比 Xen 这种 hypervisor，证明在多数服务器工作负载下容器密度更高、开销更低。

为什么重要

不读这篇，下面这些事讲不清根：

• Docker 不是凭空冒出来的——2013 年 Docker 火爆时，内核里 namespace 和 cgroups 已经做了 6 年准备，这篇论文是上游证据
• “为什么有了虚拟机还要容器”——这篇是第一次拿 benchmark 数据回答这个问题
• PlanetLab 全球研究网络当时已经用 VServer 在几百个节点上跑上千 slice，说明这套思路在工业上已被验证
• 现在云厂商谈”裸金属 vs 虚拟机 vs 容器”三档隔离，第三档的工程定义就在这里

核心要点

容器要做的事可以拆成 三层隔离：

1. 命名空间隔离（视图层）：每个容器看到自己的 PID 列表、文件树、网络接口、用户 ID。两个容器都能有 PID 1，谁也看不到对方。
2. 资源隔离（量级层）：CPU 时间、内存上限、磁盘 IO、网络带宽——每个容器一份配额，调度器按配额分。
3. 安全隔离（权限层）：root 在容器里仍是 root，但限定在容器自己的命名空间内；不能改宿主内核、不能看宿主进程。

VServer 把这三层加进 Linux 内核，叫做 context（上下文）。一个 context 就是一个容器。

对比一下两条路线的取舍：

维度	虚拟机（Xen）	容器（VServer）
隔离强度	强（独立内核）	弱（共享内核）
启动时间	秒到几十秒	毫秒级
内存开销	每 VM 一份完整 OS	共享 page cache，单租户几 MB
密度（同机几租户）	几十	几百到上千
跨内核版本	可以	不行

实践案例

案例 1：论文的核心 benchmark

作者在同一台双核 Xeon 服务器上分别跑 Xen 3.0 和 VServer，加载逐渐增加的租户数：

• 数据库（OLTP）：VServer 接近 native 性能；Xen 在 4 个 VM 时已损失 30% 吞吐
• 内核编译：VServer 几乎无损耗；Xen 因为 VM 间内存隔离损失约 25%
• 同主机最大可用租户数：VServer 可装到 100+，Xen 在内存吃紧后掉到 10 以下

结论是：对相互信任的多租户场景（同一组织内部、研究网络），容器密度优势压倒虚拟机。

案例 2：从 chroot 到容器，30 年怎么走过来

1979  chroot(2)              改根目录，最早的"文件系统视图"隔离
2000  FreeBSD jails          把 chroot + 进程视图 + 网络隔离打包
2004  Solaris Zones          加 CPU/内存配额、独立 root
2001  Linux-VServer 起步     给 Linux 加 context 概念
2007  本论文                 给容器路线写下第一份学术对照
2008  cgroups 进 Linux 主线   Google 工程师贡献，资源配额上游化
2008  LXC                    第一个用主线 namespace + cgroups 的工具
2013  Docker                 + 镜像格式 + 分层文件系统 = 大流行

VServer 是关键中间环节：它先把容器做出来给社区看，让 Linux 主线维护者愿意把 namespace 和 cgroups 收编进内核。

案例 3：今天打开 Docker 看到的就是这套

docker run -m 512m --cpus=1 ubuntu bash
ps -ef                # 容器里只看到自己的进程
cat /proc/self/status | grep NSpid
                      # PID 命名空间

-m 走 cgroup memory controller，--cpus 走 cpu controller，进程视图走 PID namespace。这些机制全部是 VServer 论文里 context 概念的主线化版本。

案例 4：密度数字背后的成本含义

假设一台 64GB 内存的服务器，托管 Web 应用：

• Xen：每个 VM 至少 1GB（OS 自身开销） + 应用 → 装 30 个就到顶
• VServer/容器：单容器仅几十 MB 元数据 + 应用 → 装 200+ 没问题

按 2007 年云价测算，密度差 6 倍意味着每用户成本差 6 倍。今天 K8s 集群密度比这还高一个量级，根源就在这套共享内核思路。

踩过的坑

1. 共享内核是双刃剑：内核漏洞（如 Dirty COW 2016）能让容器内 root 变成宿主 root。这个风险论文已经预警，至今仍是容器和虚拟机的根本差别。
2. 资源核算不全：早期 VServer 只管 CPU 和内存，对 page cache、文件描述符、内核数据结构没配额，租户能借这些”灰色资源”互相影响。后来 cgroups v2 才把核算面铺满。
3. 不是所有负载都该上容器：跑不同内核版本（Linux + 老 Solaris）、需要硬隔离（PCI 合规、加密密钥分舱）、需要跑 Windows——这些场景虚拟机仍是答案。
4. PlanetLab 经验有偏：论文 benchmark 偏服务器场景。桌面、GPU、有状态数据库这些当年没覆盖到，工业界后来补了很久。

适用 vs 不适用场景

适用：

• 多租户 Web/API 服务（同组织、相互信任）
• CI/CD 沙箱、构建机
• 微服务部署、Serverless 平台底座
• 一台机器需要装很多轻量进程组（PaaS 多应用宿主）

不适用：

• 不同操作系统共存（Linux + Windows 共主机）
• 强对抗多租户（公有云客户互相不信任）→ 用 Firecracker / Kata 这类轻量 VM
• 需要内核级深度定制（自己改调度器）的应用

历史小故事（可跳过）

PlanetLab 是普林斯顿主导的全球研究测试床——把上百所大学的服务器联网，让网络研究者部署实验。每个研究者一份 slice（切片）。每台节点要同时跑几十个 slice，但又不能让一个 slice 拖垮整机——这就是 VServer 诞生的真实压力。

作者 Larry Peterson 是 PlanetLab 的发起人；本论文不是从理论出发，而是从一个实际运行了好几年的全球网络回头总结。这也是为什么它的论证特别接地气——benchmark 不是为了刷分，是为了说服 PlanetLab 的运维同事这套方案靠谱。

6 年后 Solomon Hykes 在 dotCloud 做 Docker，把 LXC（即 namespace + cgroups 的封装）加上 union 文件系统和镜像分发，彻底引爆容器生态。Linux-VServer 这条线由于不进主线，反而被它催生的产物盖过了。

学到什么

1. 隔离是分级的——共享内核 / 共享硬件 / 完全独立，每一档都有自己的甜蜜点
2. 密度是真问题——不只是好看的数字，“一台机器能装多少租户”直接决定云的单位经济
3. 学术系统的命运不在论文本身——VServer 没进主线，但它推动主线吸收了同样的概念，间接催生了 Docker
4. 从 chroot 到容器是 30 年的渐进路——每一步只解决前一步留下的一个空缺，这是系统软件最常见的演化模式
5. benchmark 不一定要新颖才有价值——本论文跑的是工程界都熟的 PostgreSQL/Apache/内核编译，但用对照实验把”容器 vs VM 各自的甜蜜点”讲清楚，远比另起炉灶造个新 metric 更有说服力

延伸阅读

• 论文 PDF：Soltesz et al. 2007（10 页，benchmark 部分必看）
• xen-2003 —— 同时代 hypervisor 的代表作，本论文的对照组
• kvm-2007 —— Linux 把虚拟化作为内核模块的另一条路
• borg —— Google 内部容器调度器，论文同期工业界另一条线
• the-os-1968 —— 操作系统作为多任务隔离机制的原点
• 维基百科：Linux-VServer（社区视角的项目史）

关联

• xen-2003 —— 强隔离路线的代表，本论文的直接 benchmark 对手
• kvm-2007 —— 同年的另一种思路：把虚拟化做成 Linux 模块
• borg —— Google 同期已经用容器调度，工业界先行者
• borg-omega-kube-2016 —— 把容器调度推向开源主流的演进史
• exokernel-1995 —— 另一种 OS 隔离哲学：把策略全交给应用
• the-os-1968 —— 隔离/多任务这件事在 OS 的最早讨论