google/gvisor

如果你已经在用容器跑不完全信任的代码，并且希望降低单个内核漏洞带来的暴露面，gVisor 值得评估。它不是“开箱即用、性能更好”的方案，接入和维护成本是实打实的。

解决什么问题

团队把应用打包成容器，交给 Docker 或 Kubernetes 运行，并默认容器边界等于安全边界。事实并非如此：容器共享宿主机内核，一次通过容器 syscall 触达的内核漏洞就可能影响整个节点。团队希望保留 OCI 工具链和镜像工作流，同时切断这条共享内核的路径。接入 gVisor 后，容器的 syscall 由 runsc 接管，它用一个 Go 编写的用户态内核实现类似 Linux 的接口，应用仍按原有方式调用系统接口，但能触达的宿主机内核面被收窄。结果是容器照常工作，却不再直接跑在宿主内核上。

有什么不同

它的机制是“应用内核”，既不是系统调用过滤，也不是虚拟机。runsc 是 OCI 运行时，可以接入 Docker 和 Kubernetes 并使用现有镜像；项目文档明确把它与 seccomp-bpf 这类 syscall 过滤、firejail 或 AppArmor 这类隔离封装，以及 VirtualBox、QEMU 这类完整虚拟机区分开项目说明。作者宣称它具备虚拟机的隔离效果，同时资源占用更小、启动更快——这是作者的说法，输入材料中没有基准测试支撑。

最重要的取舍在于：这是对 Linux 接口的重新实现，而不是 Linux 本身。依赖冷门 syscall、特定内核行为或深度宿主机集成的应用，最可能撞上兼容性缺口，因此需要拿自己的负载去验证接口覆盖情况。它还在容器与宿主机之间多了一层运维对象：runsc 必须和它的 sidecar 二进制一起构建、一起部署，项目说明也提醒，从 go 分支构建的 runsc 不受支持项目说明。

谁值得试

适合：运行多租户或用户提交容器的平台团队，他们真正要防的是容器逃逸，且负载是普通 Linux 服务。现有 OCI 集成意味着可以先拿一部分负载试点，而不必重做镜像。

不适合：只运行自家可信服务、主要关心 syscall 吞吐的团队，额外加一层用户态内核在这一场景下并不划算；也无法接受按负载做兼容性测试的团队同样不适合。gVisor 不能替代对容器内挂载的数据和凭据做管控，README 也明确说明了这一点。

使用条件与边界

从源码构建要求 Linux 5.6+ 和 Docker 17.09.0 以上，支持 x86_64 与 ARM64，其他架构可能后续支持项目说明。构建基于 Bazel，推荐使用构建容器；直接调用 Bazel 可行但不推荐。项目另有一个 go 分支，方便把 Netstack 等子包引入 Go 项目，但属于尽力支持，不能用来构建 runsc。

长期的维护比首次构建更关键：保证 runsc 与其 sidecar 二进制成组安装，并把生产流量切过去之前，先确认负载依赖的 syscall 和内核行为在应用内核下可用。留意发布记录和兼容性文档中会影响你技术栈的变化发布说明；项目也有自己的安全策略安全策略。

HotRepo 点评

HotRepo 的样本很少：只在 2026-10-27 的 Go 月榜出现一次，排名 #13、新增 409 星。没有可比的日榜历史，无法据此判断关注度是否持续。2024-01-04 有一位评论者表示，他们在生产环境用 gVisor 跑客户负载约一年半，效果不错HN 评论——孤例，不构成共识。真正该验证的是你具体镜像的 syscall 兼容列表，而不是 Star 数。