主线08指出 Linux namespace 与 seccomp 不能组合成一句“完全安全”。当隔离目标是降低对宿主内核系统调用面的直接依赖时，gVisor 与 Kata Containers 等项目提供不同的执行路径，但它们并非“给普通 runc 加同一个开关”。要先画清应用、系统调用实现、宿主内核或 guest kernel、硬件虚拟化的边界，再讨论兼容与成本。

隔离和兼容都需对象级比较

gVisor 项目文档把它描述成在应用与宿主内核间提供用户态内核接口/拦截路径；Kata 采用轻量 VM 方向的隔离，应用与 guest kernel 交互，宿主看到 VM 资源。实际 shim 与 runtime 组合依版本实现核对，microVM 是否具备硬件虚拟化支持也是实验前提。两者对特定系统调用、文件系统路径、网络 I/O 和启动资源的处理不同，不应拿一条“启动更慢”的口号当证据。

正常案例在独立 VM 上固定同一 probe-app 镜像 digest，分别用 runc、选定版本 gVisor 和 Kata 运行相同 /ready、/state 请求，记录系统调用兼容与资源边界；反例是某调用在普通运行时可用、替代运行时拒绝或语义不同，需保留确切错误及版本后再归因，不能假设所有工作负载都能无修改迁移。硬件前提与数据表及探针包提供相同输入。云端无上述运行时、虚拟化能力未探测，比较、性能数据与拒绝案例均 NOT_RUN，只保留官方资料支持的边界模型。

现象 证据 适用条件
程序能启动 运行时版本与请求结果 不等于系统调用全兼容
有 guest kernel VM/宿主进程树 不等于与宿主无共享资源
启动耗时不同 硬件/缓存/运行时版本 不推普适损耗率

练习

  1. 预测一个探针需要新系统调用时，三种 runtime 哪些环节可能拒绝；固定具体 syscall 和版本，记录确切错误与宿主侧证据。
  2. 先画应用、guest/user-space kernel 与宿主内核边界，再在独立 VM 比较相同 digest 的启动/请求，分开报告兼容和开销。

先修：17：OCI runtime、18：containerd、35：性能设计。下一篇：E02：CRIU。

系列总目录：从进程隔离到运行时与编排。

参考资料