Linux 计算
基础设施

各层做什么，项目如何组合，新实现改变什么

容器 / 虚拟化 / 调度 / 云平台2026.09.23

一张地图：从执行能力到云服务

L6云服务向租户交付资源OpenStack

L5调度与编排分配资源、维持期望状态Kubernetes / Ray

L4使用与管理入口组织实例生命周期Docker / libvirt / Incus

L3节点运行时管理镜像与执行任务containerd / CRI-O

L2执行实现启动进程或虚拟机runc / gVisor / QEMU

L1内核机制实施隔离与资源控制namespaces / cgroups / KVM

L0硬件能力支持 CPU 与设备虚拟化VT-x / AMD-V / IOMMU

按职责分组，平台可以跨层。具体调用路径不必经过每一层。

两条调用链：执行态与层间接口

应用容器

L5Kubernetes 控制面用户态

↕ HTTPS API · kubelet 发起 watch

L5kubelet用户态

↓ CRI / gRPC

L3containerd用户态

↓ ttRPC / Unix socket

L3/2shim-runc-v2用户态

↓ fork/exec + OCI bundle

L2runc用户态

↓ 系统调用 / 写 cgroupfs

L1namespaces / cgroups内核态

虚拟机 · Proxmox VE

L4PVE API / pveproxy用户态

↓ 本地 HTTP · 转交特权操作

L4pvedaemon / qemu-server用户态

↓ 启动 QEMU 进程，QMP 管理

L2QEMU用户态

↓ /dev/kvm + ioctl

L1KVM内核态

↕ VM entry / exit · 以 x86 为例

L0VT-x / AMD-V硬件

宿主机视角。箭头表示控制与启动关系，运行时 I/O 不必经过所有管理层。

建议用时 130 秒

先沿两条链各走一遍。蓝色均为宿主用户态组件，即使以 root 运行也一样。kubelet 主动从 API 获取分配给本节点的 Pod，通过 CRI 的 gRPC 调用 containerd；containerd 经 ttRPC 连接 containerd-shim-runc-v2，shim 再启动 runc。最后由系统调用和 cgroupfs 进入内核机制。右边以在 Proxmox VE 网页启动本节点 VM 为例：浏览器通过 HTTPS 访问 8006 端口的 pveproxy，特权操作转交本地 HTTP 服务 pvedaemon（127.0.0.1:85）。pvedaemon 的任务执行路径调用 qemu-server 包中的 VM 管理逻辑，准备配置、启动 QEMU，并通过 Unix socket 上的 QMP 管理它。qemu-server 是管理代码和工具，不是额外的常驻 daemon。QEMU 用 /dev/kvm ioctl 调用 KVM，KVM 再使用硬件虚拟化。这里不经过 libvirt。图中 L4 表示该启动路径的实例管理职责，Proxmox VE 整个平台还覆盖 L5 集群与 HA。完整组件说明在本页下方详解。

官方来源：S02　S03　S06　S20　S22　S26

两条调用链校准项目所在层次

执行态按宿主机视角标注；用户态服务即使以 root 运行，也不属于内核态。

应用容器 · runc 路径

Kubernetes 控制面用户态L5 · 工作负载控制

↕ Kubernetes API / HTTPS · kubelet 发起 list/watch

kubelet用户态L5 的节点代理 · 协调执行

↓ CRI / gRPC · Unix socket

containerd用户态L3 · 节点运行时，包含 CRI 插件

↓ shim v2 / ttRPC · Unix socket

containerd-shim-runc-v2用户态L3 → L2 · 执行适配与进程监护

↓ fork/exec 启动 runc · 传入 OCI bundle

runc用户态L2 · 按 OCI 配置创建容器进程

↓ 系统调用：clone / setns 等；写 cgroupfs

namespaces / cgroups内核态L1 · 隔离视图与资源控制

虚拟机 · Proxmox VE 路径

Proxmox VE API用户态L4 · pveproxy 接收 HTTPS API 请求

↓ 本地 HTTP · 127.0.0.1:85 · 特权操作

PVE VM 管理用户态L4 · pvedaemon / qemu-server 管理逻辑

↓ 启动 QEMU；QMP / JSON + Unix socket 管理

QEMU用户态L2 · VMM，构建虚拟机与设备模型

↓ /dev/kvm + ioctl · 包括 KVM_RUN

KVM内核态L1 · 提供 VM / vCPU 执行机制

↕ 硬件虚拟化指令 · VM entry / exit（以 x86 为例）

硬件虚拟化硬件L0 · CPU 的 VT-x / AMD-V 等能力

箭头表示控制、启动与接口关系，省略部分内部组件；并非每条指令或每次 I/O 都经过全部管理层。

按需纵向详解，不计入主线用时

这页按宿主机视角区分用户态、内核态与硬件：有 root 权限的守护进程仍然是用户态程序。左边控制面保存工作负载状态，kubelet 主动通过 Kubernetes API 的 HTTPS list/watch 获取分配给本节点的 Pod，不能理解为调度器直接 RPC 推送到 kubelet。kubelet 通过 CRI 的 gRPC、通常经 Unix socket 调用 containerd 的 CRI 插件；CRI 是接口而不是进程。containerd 通过 shim v2 的 ttRPC socket 与 containerd-shim-runc-v2 通信，shim 再 fork/exec runc 并传入 OCI bundle。runc 调用 clone、unshare、setns、mount 等系统调用并写 cgroupfs，最终由内核实施隔离和资源限制，写 cgroupfs 本身也通过系统调用。右边是 Proxmox VE 的网页启动 VM 路径。pveproxy 在 HTTPS 8006 端口接收请求，把需要特权的操作转交本地 127.0.0.1:85 上的 pvedaemon。任务执行路径调用 qemu-server 的管理逻辑，准备配置并启动 QEMU，再通过 Unix socket 上的 QMP 管理虚拟机。qemu-server 是管理代码与工具包，不应误读为独立常驻进程。默认路径不使用 libvirt。QEMU 打开 /dev/kvm，通过包括 KVM_RUN 在内的 ioctl 使用 KVM。KVM 使用硬件虚拟化并协调 VM entry/exit，这里以 x86 为例。Proxmox VE 的集群转发、HA、存储和网络细节在图中省略。所有执行态均以宿主视角说明，guest 自己的权限级别是另一维度。

官方来源：S02　S03　S06　S20　S22　S26

L0 / L1：提供执行与隔离机制

上层提出要求，内核与硬件负责实施

功能	核心机制	演进重点
隔离进程视图	namespaces	与权限、挂载机制组合
限制资源使用	cgroups	v1 → v2：统一层级与委派
执行 guest	KVM + 硬件虚拟化	新设备、架构与机密计算

sudo unshare --uts sh -c 'hostname demo; hostname'
hostname

子进程看到 demo，外层仍看到原主机名。

建议用时 80 秒

这一层回答能力从哪里来。namespaces 隔离进程看到的系统视图，cgroups 控制资源使用，KVM 配合硬件执行 guest。它们仍需要上层配置与管理，不能单独成为完整平台。以 cgroups v2 为例，演进常常是改善机制的组合方式。命令示例（Linux shell）： sudo unshare --uts sh -c 'hostname demo; hostname' hostname 前提：Linux + sudo。预期作用：子进程看到 demo，外层仍看到原主机名。 unshare 是用户态工具，它调用内核建立新的 UTS namespace。第一行只隔离主机名视图，不隔离文件系统、网络或资源，也不创建完整容器。第二行在原来的 shell 中执行。依赖 util-linux、hostname 和允许创建 namespace 的 Linux 环境。L0 是硬件能力，没有对应的“启动平台”命令；可用 lscpu 查看 x86 的 VT-x/AMD-V 暴露情况，但这不能单独证明 /dev/kvm 可用。命令参考：https://man7.org/linux/man-pages/man1/unshare.1.html

官方来源：S02　S03　S04　S05

硬件与内核术语速查

术语	负责什么
VT-x / AMD-V / Arm EL2	CPU guest 执行模式与受控陷入
EPT / NPT / Stage-2	guest physical 到 host physical 的内存地址翻译
IOMMU / VFIO	设备 DMA 约束与设备直通的内核支持
SR-IOV	一块 PCIe 设备暴露多个 Virtual Functions
cgroups v2	统一资源控制层级与委派语义
user namespace / idmapped mount	身份映射与挂载上的文件所有权映射

L2：OCI runtime 把配置变成进程

OCI（Open Container Initiative）制定容器开放标准。
镜像规范管打包，分发规范管传输，运行时规范管启动。

实现	主要特色	比较重点
runc	经典基线，生态成熟	兼容与集成
crun	C 实现，强调小体积	启动与内存开销
youki	Rust 实现	内存安全与功能覆盖

sudo runc run --bundle ./bundle demo

config.json 指定命令与隔离设置，rootfs 提供程序与文件。

建议用时 75 秒

OCI 全称 Open Container Initiative，中文可称开放容器倡议，是制定容器开放标准的组织。这里记住三个范围：image-spec 约定镜像如何打包，distribution-spec 约定镜像如何分发，runtime-spec 约定容器的运行配置与生命周期。OCI 本身不是某个运行时程序。runc、crun、youki 是实现运行时规范的程序，可以在接口支持范围内比较和替换。命令里的 OCI bundle 是运行准备目录：config.json 描述要执行的命令、挂载与隔离设置，rootfs 提供容器看到的根文件系统，其中包含程序与依赖。镜像需要解包并配好运行配置，才能交给 runc；runc 不负责从镜像仓库下载镜像。运行时组织建立命名空间、挂载、权限配置和执行程序的顺序。语言不同只解释一部分设计差异，不能直接推导全面更快或更安全。命令示例（Linux shell）： sudo runc run --bundle ./bundle demo 前提：已准备 bundle：config.json + rootfs/。预期作用：config.json 指定命令与隔离设置，rootfs 提供程序与文件。 bundle 是目录，包含 config.json 和 rootfs/。在该目录用 runc spec 生成模板，再设置 process.args 为 ["/bin/echo", "hello"]、process.terminal 为 false；rootfs 中需有 /bin/echo 及其依赖。root.path 指向 rootfs，宿主支持配置要求的 namespaces/cgroups。命令成功时输出 hello 并退出；runc 不负责下载镜像，也不要求 containerd 或 Kubernetes。演示使用未占用的容器 ID demo。命令参考：https://github.com/opencontainers/runc#using-runc

官方来源：S01　S06　S07　S08

OCI：从镜像到运行中的进程

三个规范连接不同环节，runc 接收的是运行准备目录。

规范	约定什么	具体产物 / 交互
Image Spec	程序和依赖如何打包	镜像层、配置、manifest
Distribution Spec	如何推送和拉取内容	客户端与 registry 的分发 API
Runtime Spec	容器配置与生命周期	bundle、create / start / delete 等

交给 runc 的 OCI bundle

bundle/
  config.json   # 命令、挂载、隔离设置
  rootfs/       # 程序、库和容器文件

谁把它准备好？

上层拉取并解包镜像，准备 rootfs 与运行配置。
runc 据此调用内核，创建并启动进程。

L2：沙箱改变应用到宿主的边界

上层仍管理容器，底层执行路径可以改变

路径	隔离方式	主要代价
普通容器	应用直接使用宿主内核	共享内核的信任边界
gVisor	用户态 Sentry 实现 Linux 接口	兼容与 I/O 需验证
Kata Containers	容器运行在独立 guest 内核中	引入 VM 管理与资源开销

sudo runsc run --bundle ./bundle sandbox-demo

执行同一个 hello 程序，Linux 接口由 Sentry 承接。

建议用时 85 秒

这里关注信任边界的变化。gVisor 减少应用直接暴露给宿主的接口，Kata 引入 guest 内核和 VM 边界。Kata 需要 QEMU 或其他 VMM，因此不能把 Kata 与 QEMU 简单当成同层替代。隔离方式、兼容、设备和成本需要一起判断。命令示例（Linux shell）： sudo runsc run --bundle ./bundle sandbox-demo 前提：已准备兼容的 OCI bundle。预期作用：执行同一个 hello 程序，Linux 接口由 Sentry 承接。按 gVisor OCI quick start 准备受 runsc 支持的 rootfs 和 config.json，设置 process.args 为 ["/bin/echo", "hello"]、process.terminal 为 false。语义沿用上一页的 hello 程序，但应核对 OCI 配置支持范围。需要安装 runsc、满足所选平台的宿主要求。这里直接使用 runsc，不依赖 Docker 或 Kubernetes。gVisor 仍调用受限宿主接口，不是完全脱离宿主内核。命令参考：https://gvisor.dev/docs/user_guide/quick_start/oci/

官方来源：S10　S12

普通容器、gVisor、Kata 的执行路径

它们是可选执行路径，各自把隔离边界放在不同位置。

普通 OCI 容器

应用进程↓ Linux 系统调用宿主 Linux 内核

共享宿主内核
namespaces / cgroups 等实施约束

gVisor

应用进程↓ Linux 接口由 Sentry 承接Sentry · 用户态↓ 受限宿主接口宿主 Linux 内核

减少直接暴露的宿主接口
需要验证兼容与 I/O

Kata Containers

应用 + guest 内核↓ 虚拟硬件接口VMM + 宿主 KVM

独立 guest 内核与 VM 边界
增加机器与 guest 管理

接口相近不代表边界相同；设备直通和恢复能力仍取决于具体后端。

L2：VMM 在通用性与精简之间取舍

KVM 提供执行能力，VMM 组织机器与设备模型

实现	核心取向	主要取舍
QEMU	广架构、广设备、成熟生态	兼容面与实现规模较大
Cloud Hypervisor	现代云 VM，virtio / VFIO	减少遗留设备支持
Firecracker	精简 microVM，快照恢复	通用设备能力较窄

qemu-system-x86_64 -enable-kvm -m 1024 \
  -drive file=guest.qcow2,format=qcow2 -snapshot -nographic

启动一台 1 GiB VM，本次磁盘写入放在临时层。

建议用时 100 秒

经典 QEMU 的价值在广泛兼容与积累的管理生态。Cloud Hypervisor 面向现代云 VM，并不只做短任务。Firecracker 更积极裁剪设备模型，面向精简 microVM。快照恢复与通用在线迁移是不同能力。crosvm、libkrun 和具体设备限制留作答疑。命令示例（Linux shell）： qemu-system-x86_64 -enable-kvm -m 1024 \ -drive file=guest.qcow2,format=qcow2 -snapshot -nographic 前提：可启动的 guest.qcow2 + /dev/kvm 权限。预期作用：启动一台 1 GiB VM，本次磁盘写入放在临时层。示例针对 x86 Linux 宿主和可在默认 PC/磁盘控制器配置下启动的 x86 qcow2 系统盘。宿主需安装 QEMU、启用 KVM，当前用户能够读写 /dev/kvm；guest 需配置串口控制台才能在 -nographic 下看到登录输出。-snapshot 使用临时磁盘写入层，不是 VM 内存快照。可用 Ctrl-a x 退出 QEMU，临时磁盘写入不会保留。不需要 libvirt 或 Proxmox，机器配置和生命周期由调用者自己负责。命令参考：https://www.qemu.org/docs/master/system/invocation.html

官方来源：S03　S14　S15　S16

VMM 迁移与设备能力

VMM	设备能力侧重	状态与迁移边界
QEMU	设备/guest 广，VFIO 生态成熟	成熟迁移机制，仍受 CPU、设备、版本限制
Cloud Hypervisor	现代 virtio、VFIO、热插拔	有 live migration，不保证跨版本兼容
Firecracker	精简设备；virtio PCI 热插拔为开发预览	snapshot/restore 不等于通用 live migration
crosvm	客户端设备、独立设备进程、VFIO 路径	官方 snapshot 文档标为高度实验性

核验日：2026-09-23。上游 VMM 有能力，不代表每个管理平台都已支持。

L3：节点运行时长期管理镜像与任务

把一次性的底层执行，组织成持续运行的节点服务

实现	管理范围	特色
containerd	镜像、快照、任务与插件	服务 Kubernetes、Docker 等上层
CRI-O	Pod sandbox 与容器生命周期	围绕 Kubernetes CRI 聚焦设计

sudo ctr images pull docker.io/library/alpine:3.22
sudo ctr run --rm docker.io/library/alpine:3.22 demo echo hello

先管理镜像，再经 shim / runc 启动任务，输出 hello。

建议用时 80 秒

runc 创建容器，但节点还需要长期维护镜像、rootfs、任务和退出状态。containerd 与 CRI-O 在 Kubernetes 节点角色上是候选。containerd 的通用插件框架支持更多上层，CRI-O 聚焦 CRI。snapshotter 和 shim 的细节只在提问时展开。命令示例（Linux shell）： sudo ctr images pull docker.io/library/alpine:3.22 sudo ctr run --rm docker.io/library/alpine:3.22 demo echo hello 前提：containerd 已运行，可访问镜像仓库。预期作用：先管理镜像，再经 shim / runc 启动任务，输出 hello。 ctr 是 containerd 自带的低层管理/调试客户端。第一行拉取并解包镜像，第二行在默认 containerd namespace 中创建并执行临时容器。需要 containerd、containerd-shim-runc-v2 与 runc 等执行依赖；ID demo 应未被占用。--rm 清理本次容器/任务，不删除已拉取的镜像。这里直接调用 containerd API，不经过 CRI，也不需要 kubelet；本例仅执行 echo，不要求配置容器网络。命令参考：https://github.com/containerd/containerd/tree/main/cmd/ctr

官方来源：S20　S21　S22

接口定义上下层怎样组合

不同接口连接不同职责，不能串成一条 OCI / CRI / CNI / CSI 流水线

接口	连接双方	约定的主要功能
OCI	镜像生产/消费方、执行管理方与 runtime	镜像、分发、运行规范各有边界
CRI	kubelet 与节点运行时	Pod sandbox、容器、镜像等 RPC
CNI	网络调用方与网络插件	接入、配置与清理容器网络
CSI	存储控制/节点组件与驱动	卷供应、挂载、扩容等
libvirt / QMP	管理客户端与虚拟化管理层 / QEMU	分别提供管理抽象与具体 VMM 控制

Kubernetes API 则统一对象与期望状态，CRD / controller 在这个层面扩展能力。

L4：把执行能力组织成管理入口

共同关注生命周期，管理对象与产品范围各不相同

对象	代表实现	关键区别
应用容器	Docker / Podman	完整开发生态 / 无必需中心 daemon
VM 管理接口	libvirt	封装 VMM 控制，供上层调用
完整实例平台	Incus / Proxmox	统一实例 API / 集成虚拟化运维

qm start 101
qm status 101

复用已保存的 CPU、磁盘与网络配置，启动并查询 VM。

建议用时 90 秒

这一页合并入口与实例管理。Docker、Podman 面向容器使用者，libvirt 面向需要管理 VMM 的程序，Incus 和 Proxmox 进一步整合网络、存储与集群。Podman 强调 rootless 和 systemd 集成，Docker 也支持 rootless。Incus 当前支持系统容器、OCI 应用容器与 VM；Proxmox 默认 QEMU 管理不经 libvirt。命令示例（Linux shell）： qm start 101 qm status 101 前提：已配置、处于停止状态的测试 VM 101。预期作用：复用已保存的 CPU、磁盘与网络配置，启动并查询 VM。在拥有相应权限的 Proxmox VE 节点上执行，示例使用 root shell。101 是该节点已配置的测试 VM ID，磁盘、内存、网桥等资源应已就绪；不是任意安装了 Linux 的机器都能运行此命令。qm 使用 PVE 自身管理逻辑，省去手写 QEMU 启动参数。这是本地 CLI 路径，不经过网页入口 pveproxy；它和网页 API 复用管理代码。qm status 101 预期显示 status: running，但并不证明 guest 已完成启动。演示后可在 guest 内正常关机或使用 qm shutdown 101。命令参考：https://pve.proxmox.com/pve-docs/qm.1.html

官方来源：S23　S26　S27　S28　S31

L4：Docker 与 Podman 面向使用者

把镜像、网络、卷、构建和交互操作组织成用户工作流

维度	Docker · 经典生态	Podman · 不同管理路线
进程架构	dockerd + containerd 等组件	无必需中心 daemon，可开 API service
权限与服务管理	支持 rootless，成熟开发生态	强调 rootless 与 systemd / Quadlet
构建与应用组合	BuildKit / buildx / Compose	Buildah 生态，Compose provider
替换边界	CLI、Engine API、Desktop 各有范围	需验证 API、构建与 Compose 兼容

共享 OCI 生态，但 Engine API、构建器和开发工作流并非全部相同。

L4：Incus 统一不同类型的实例

承接 LXC / LXD 的机器式管理路线，并统一容器与 VM

Incus 实例 API / 集群

系统容器

init / systemd、多服务

LXC / liblxc
共享宿主内核

OCI 应用容器

当前已支持 OCI 镜像

应用启动语义
仍有自身执行与管理路径

虚拟机

独立 guest 内核

QEMU / KVM
完整系统环境

统一管理：镜像、存储、网络、快照、项目、资源限制与集群

LXD 仍在维护。Incus 的 OCI 支持不等于 Docker API，也不意味着改用 containerd。

L5：调度分配资源，编排维持状态

Kubernetes 放置 Pod；Ray 在集群内调度 task / actor

实现	组织中心	主要优势
Kubernetes	对象 API 与控制器	工作负载调谐与扩展生态
Ray	task / actor 与逻辑资源	分布式 Python、CPU / GPU 任务调度
Kueue / Volcano	Kubernetes 上的批处理能力	准入配额 / gang scheduling

ray job submit --address http://127.0.0.1:8265 \
  --working-dir . -- python demo.py

提交 Ray 作业；脚本中的 task / actor 再由 Ray 调度。

建议用时 90 秒

调度存在不同范围。Kubernetes 的调度器放置 Pod，控制器协调期望状态。Ray 是分布式应用框架，task 是远程函数调用，actor 是保留状态的工作进程；Ray 在节点公布的逻辑资源上安排它们执行。Ray 可以直接运行在物理机或 VM，也可以通过 KubeRay 部署在 Kubernetes 上；后一种情况下 Kubernetes 管 Pod 放置，Ray 继续做应用任务调度。num_cpus、num_gpus 是逻辑资源需求，不等同 cgroups 的 CPU/内存硬限制，也不能当成安全隔离。Kueue 主要管理准入与配额，Volcano 提供批处理控制器和调度器。页面命令提交的是 Ray Job，即启动 driver 的入口；真正的 task / actor 调度由脚本内的 Ray API 触发。命令示例（Linux shell）： ray job submit --address http://127.0.0.1:8265 \ --working-dir . -- python demo.py 前提：可用 Ray 集群和 Jobs 服务，当前目录含 demo.py。预期作用：提交 Ray 作业；脚本中的 task / actor 再由 Ray 调度。在独立演示目录中准备下方 demo.py，并安装带 Dashboard / Jobs 依赖的 ray[default]。本地演示可先用 ray start --head --num-cpus=2 启动测试集群，按其输出确认 Jobs 服务地址；默认使用本地 8265 端口。--working-dir . 会打包当前目录并上传给集群，因此应使用只包含演示文件的小目录。命令启动 driver，脚本中的 square.remote 再产生四个 Ray task；成功时输出 [0, 1, 4, 9]。Ray 可独立运行，不要求 Kubernetes。CPU / GPU 声明是逻辑调度资源，不构成内核级资源硬限制。演示结束仅对本次专用测试集群运行 ray stop，不要停止共享 Ray 服务。命令参考：https://docs.ray.io/en/latest/cluster/running-applications/job-submission/quickstart.html

官方来源：S41　S37　S39　S62　S72

KubeVirt：在 Kubernetes 中管理 VM

改变 VM 的管理方式，复用既有虚拟化执行栈

VM / VMI 对象声明虚拟机与运行实例

KubeVirt controllers协调状态与 launcher Pod

节点组件 / libvirt连接 VM 管理接口

QEMU / KVM执行 guest

virtctl start demo-vm
kubectl get vm,vmi

将 VM 置为启动状态，由控制器创建运行实例 VMI。

建议用时 80 秒

KubeVirt 在 Kubernetes API 中增加 VM 和 VMI，通过控制器、launcher 和节点组件管理虚拟机。容器节点运行时承载 launcher Pod，里面的 VM 继续依赖 libvirt、QEMU、KVM。因此两条路径在这里组合。网络、存储和设备仍需要具体集成。命令示例（Linux shell）： virtctl start demo-vm kubectl get vm,vmi 前提：集群中已有停止的 demo-vm 对象。预期作用：将 VM 置为启动状态，由控制器创建运行实例 VMI。集群已安装 KubeVirt，virtctl 与集群版本兼容，VM 对象、系统盘及可用节点已准备好。VM 需要允许手动启动的 runStrategy 或等效运行策略。命令作用于当前 namespace，不是从零创建系统盘。启动后查询 VM 和 VMI 的状态；后端通过 launcher、节点组件、libvirt 与 QEMU/KVM 完成执行。演示后可用 virtctl stop demo-vm 停止本次运行实例。命令参考：https://kubevirt.io/user-guide/user_workloads/virtual_machine_instances/

官方来源：S24　S46

L6：云平台向租户交付资源服务

在执行与管理之上，增加租户、权限、网络和存储契约

职责	OpenStack 经典实现	交付内容
计算	Nova / Placement	实例生命周期与资源分配
网络与存储	Neutron / Cinder / Glance	网络、卷与镜像
身份与租户	Keystone	项目、角色与授权基础

openstack server create --image demo-image --flavor m1.small \
  --network demo-net --wait demo-vm

申请租户 VM：云平台协调配额、计算、镜像与网络。

建议用时 95 秒

OpenStack 按服务领域组织，Nova 通过 libvirt、QEMU、KVM 使用下层能力。Placement 提供资源库存与 allocation 等信息，与 Nova 协作。Kubernetes 加 KubeVirt 提供另一种控制面组织方式，云租户、网络、存储和运营工作仍要承担。Harvester 是整合平台示例，不能把 KubeVirt 单个扩展等同完整 IaaS。命令示例（Linux shell）： openstack server create --image demo-image --flavor m1.small \ --network demo-net --wait demo-vm 前提：已认证，镜像 / 规格 / 网络已存在。预期作用：申请租户 VM：云平台协调配额、计算、镜像与网络。需要 OpenStack CLI 和有效的 clouds.yaml / OS_CLOUD 或环境变量认证；demo-image、m1.small、demo-net 是当前云中可访问的示例资源名，需替换为真实资源。项目配额、后端容量和网络需满足请求。--wait 等待构建完成，成功时实例通常为 ACTIVE；这不等于已能 SSH，密钥、安全组、浮动 IP 需另行配置。客户端访问云 API，真正执行仍依赖 Nova、具体 VMM 和宿主内核。此例不显式请求持久卷，不表示每次创建 VM 都调用 Cinder。演示结束可用 openstack server delete --wait demo-vm 删除本次示例实例。命令参考：https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html

官方来源：S25　S43　S46　S52

新实现主要改变三类设计选择

功能范围QEMU → 专用 VMM
减少兼容包袱，优化目标工作负载

执行边界普通容器 → gVisor / Kata
改变隔离方式，承担兼容与管理成本

管理模型VM 平台 API → KubeVirt 对象
复用 Kubernetes 控制器与生态

评价“新”的依据：具体收益，以及为此放弃了什么。

编码 Agent：sandbox 做在哪一层？

本地 CLI，Linux 为主 · 核验：2026-09-24 · 文档 / 源码分支快照

Agent	有无、机制与层次	能限制什么 / 边界
Codex	有 · L2 执行封装 → L1 内核 bubblewrap + seccomp	文件访问、进程可见性与网络审批另设，实际限制取决于配置
Claude Code	有 · L2 执行封装 → L1 内核 bubblewrap + 网络代理	shell 进程树的文件与网络访问可配置沙箱外重试
Pi	本体无 · Agent 内信任 / 扩展逻辑可外接容器、sandbox 或 VM	项目信任控制资源加载执行隔离由外部环境提供
OpenCode	本体无 · Agent 内工具权限策略官方建议外接容器 / VM	allow / ask / deny 控制工具调用权限审批不构成 OS 隔离

审批与信任属于 Agent 逻辑；执行沙箱调用内核机制强制限制访问。

建议用时 85 秒

本页限定本地编码 CLI，并以 Linux 路线映射前面的层次；不是比较云托管产品，也不是安全强弱排名。Codex 当前官方 main 分支的 linux-sandbox README 说明：文件系统隔离默认使用 bubblewrap，配合 user/PID/network namespaces、只读和可写挂载、seccomp，以及可选受管网络代理；不能沿用旧资料把 Landlock 写成当前唯一或默认后端。这里说明的是已有机制，实际是否启用、可访问哪些路径和网络取决于运行配置。Claude Code 官方文档说明，可通过 /sandbox 启用 shell 命令及子进程的隔离，Linux 使用 bubblewrap 和代理控制，macOS 使用 Seatbelt；其产品文档当前要求 Windows 使用 WSL2。Read/Edit/MCP 等其他工具的覆盖范围要分别核实，不能推成整个 Agent 及所有扩展都已被隔离。沙箱外重试和 excludedCommands 也会改变边界。Pi 指 Pi coding agent，当前仓库为 earendil-works/pi，原 badlogic/pi-mono；官方明确本体无 sandbox，项目 trust 只控制资源加载，工具和扩展默认使用 Pi 进程的 OS 权限。官方给出整进程置于 Docker、Docker Sandboxes、OpenShell 等外部环境的方案；只包装工具时，Pi 与扩展仍可能在边界外。OpenCode 官方 SECURITY.md 明确 No Sandbox；allow/ask/deny 可以管理工具调用，但不是 OS 安全边界，官方建议在 Docker 或 VM 中运行以获得隔离。层次归属是本汇报的分析：Agent 权限判断属于应用逻辑，命令沙箱封装归 L2，Linux 内核落实隔离归 L1。核验的是文档与固定源码快照，未做逃逸测试，也不保证每个已发布包与分支一致。详细来源、commit 和限制见《Agent沙箱机制调研.md》。

官方来源：S66　S67　S68　S69　S70　S71

Codex / Claude Code：限制如何落到 OS？

Linux 路线：Agent 配置策略，执行封装与内核共同实施限制。

限制对象	执行封装怎么做	实际边界
文件	只读 / 可写挂载，拒绝或屏蔽路径	进程能读取或修改哪些文件
进程与系统接口	namespaces、权限收紧、seccomp	可见性与允许使用的系统接口
网络	网络隔离 + 受控代理 / 过滤	能否出站，以及允许的目的地

审批负责是否放行；sandbox 限制放行后的执行。沙箱外重试会改变这条边界。

此表归纳两者涉及的机制，并不表示它们使用完全相同的配置、过滤规则或覆盖范围。

Pi / OpenCode：外部隔离要包住哪些进程？

本体无 OS sandbox 时，部署边界决定哪些操作真正受限。

部署方式	受约束的范围	仍需留意
仅设信任 / 审批	项目资源加载或工具调用	进程仍使用原有 OS 权限
仅把工具放进 sandbox	被包装的命令与子进程	Agent、扩展或其他工具可在边界外
整个 Agent 放入容器 / VM	Agent、扩展及其子进程	挂载、凭据、网络和外部服务仍需配置

Pi 官方列出整进程与工具级隔离方案；OpenCode 官方建议外接 Docker 或 VM。

可访问的宿主目录与凭据仍然可被使用；运行在容器中不自动等于无宿主访问能力。

定位项目：职责、接口、取舍

执行层内核与硬件提供机制
runc、gVisor、QEMU 组织执行

管理层containerd、libvirt、实例平台
维护镜像、任务与生命周期

集群与云Kubernetes、Ray、OpenStack
分配共享资源，交付服务

同层看取舍，上下层看接口。
我们的工作应该复用哪些层，新增哪一层能力？

附录：完整执行链路

Docker
CLI → dockerd → containerd → shim → runc → Linux 内核机制

Kubernetes 容器
API → controller / scheduler → kubelet → CRI → 节点 runtime

Kubernetes 虚拟机
KubeVirt → launcher Pod / libvirt → QEMU → KVM → guest

OpenStack 虚拟机
Nova → libvirt → QEMU → KVM → 硬件虚拟化

这些是管理与启动链路。运行中应用的数据访问不逐次穿过所有管理组件。

附录：容器管理项目怎样比较

比较	关系	替换前需要确认
runc / crun / youki	同层 OCI 执行器	特性覆盖、rootless、hooks、上层集成
containerd / CRI-O	Kubernetes 节点运行时候选	CRI 兼容、镜像/存储/沙箱集成
Docker / Podman	用户 engine 工作流候选	API、Compose、构建与 systemd 工作流
Incus / Proxmox	实例与虚拟化平台候选	集群、存储、备份、权限与运维体验
Incus / Kubernetes	存在场景重叠，主要对象不同	机器式实例与工作负载控制器体系

附录：GPU 会改变执行与安全边界

路径	应用如何访问 GPU	需要特别确认
普通容器 / Incus 容器	共享宿主 GPU 驱动与设备节点	驱动攻击面、资源隔离与配额
gVisor	nvproxy 转发受支持的 NVIDIA ioctl	驱动与功能覆盖，仍存在宿主驱动边界
Kata / VM	直通或虚拟设备，取决于 VMM/集成	IOMMU、设备重置、guest 驱动与兼容
checkpoint / migration	依赖 GPU 和软件栈专门支持	不能从普通 VM 快照能力自动推导

gVisor 已有 cuda-checkpoint 集成。当前文档指出该 GPU 恢复路径不支持 arm64。

附录：四种“恢复”语义

状态类型	主要保存什么	典型遗漏
文件系统快照	文件或块设备内容	运行中内存、连接与外部副作用
进程 checkpoint	地址空间、线程与部分内核对象	设备、不同内核环境与外部服务状态
VM snapshot	vCPU、guest 内存与设备状态	磁盘可能需另管，版本/CPU 可能不兼容
应用 checkpoint	应用主动保存的可继续计算状态	依赖应用实现，未必保留交互环境

API 应返回快照范围与一致性级别，避免只提供含糊的 rollback。

附录：项目状态与时效性

项目或能力	核验日所见状态
Incus / LXD	都仍维护，Incus 已有 OCI 应用容器文档
Mesos / Nabla runnc	Mesos 已退休，runnc 已归档
Kueue / DRA	Kueue 通常沿用默认调度器，DRA 主功能自 v1.35 稳定
Daytona 原公开核心仓库	2026 年 6 月起不再维护，核心开发转私有
agent-sandbox / E2B Runtime	已有公开 Agent 沙箱管理与执行基础

资料核验：2026-09-23。项目仍维护与某项功能生产可用，是不同判断。

附录：官方资料阅读入口

机制与接口
Linux KVM API　OCI　Kubernetes CRI

隔离与执行
gVisor 架构　 Kata Containers　Firecracker

调度与控制面
Kueue Overview　KubeVirt　Nova 架构

Agent 执行平台
agent-sandbox　E2B Runtime

Linux 计算基础设施

一张地图：从执行能力到云服务

两条调用链：执行态与层间接口

应用容器

虚拟机 · Proxmox VE

两条调用链校准项目所在层次

应用容器 · runc 路径

虚拟机 · Proxmox VE 路径

L0 / L1：提供执行与隔离机制

硬件与内核术语速查

L2：OCI runtime 把配置变成进程

OCI：从镜像到运行中的进程

L2：沙箱改变应用到宿主的边界

普通容器、gVisor、Kata 的执行路径

普通 OCI 容器

gVisor

Kata Containers

L2：VMM 在通用性与精简之间取舍

VMM 迁移与设备能力

L3：节点运行时长期管理镜像与任务

接口定义上下层怎样组合

L4：把执行能力组织成管理入口

L4：Docker 与 Podman 面向使用者

L4：Incus 统一不同类型的实例

系统容器

OCI 应用容器

虚拟机

L5：调度分配资源，编排维持状态

KubeVirt：在 Kubernetes 中管理 VM

L6：云平台向租户交付资源服务

新实现主要改变三类设计选择

编码 Agent：sandbox 做在哪一层？

Codex / Claude Code：限制如何落到 OS？

Pi / OpenCode：外部隔离要包住哪些进程？

定位项目：职责、接口、取舍

附录：完整执行链路

附录：容器管理项目怎样比较

附录：GPU 会改变执行与安全边界

附录：四种“恢复”语义

附录：项目状态与时效性

附录：官方资料阅读入口

Linux 计算
基础设施