Agent Substrate的gVisor后端一篇讲透：runsc checkpoint/restore原理

Agent Substrate的gVisor后端一篇讲透runsc checkpoint/restore原理【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateAgent Substrate 是一个面向 AI Agent 时代的安全沙箱执行运行时其 gVisor 后端通过runsc的 checkpoint/restore 机制把 Actor 的进程内存与磁盘状态整体“冻结”再“复活”实现亚 500ms 的恢复resume和每秒 500 次的挂起/恢复吞吐。本文带你彻底看懂这套机制checkpoint 怎么拍快照、restore 怎么瞬间还原以及 Substrate 在 gVisor 之上做了哪些工程细节。一、为什么选 gVisor 做沙箱后端Agent Substrate 的设计目标很明确把大量“大部分时间都在等待”的 Agent 应用Actor高密度地复用到少量物理 Worker Pod 上。它需要一种既安全、又能整体迁移的隔离技术于是支持了两类沙箱沙箱类型配套组件挂起/恢复机制gVisor默认ateom-gvisor原生runsc checkpoint/runsc restore捕获整个沙箱化进程树micro-VMateom-microvmKata Cloud Hypervisor内存快照 userfaultfd 按需分页gVisor 的优势在于它是用户态内核Sentry沙箱内的进程树完全是 gVisor 自己管理的对象。这意味着整个沙箱状态可以被序列化成文件——内存、打开的文件描述符、socket 连接全部在内核的“视野”内checkpoint/restore 因此可以做到既完整又快速而且天然防容器逃逸。关于两类沙箱的定位可以阅读 docs/architecture.md 中 “Sandbox Classes” 一节。二、gVisor 后端的角色分工atelet ateom-gvisor runscSubstrate 的 gVisor 后端不是直接跑runsc而是三层协作atelet节点级 DaemonSet负责拉取镜像、组装 OCI bundle、下载/上传快照然后通过 gRPC 驱动 Worker Pod 内的 ateom。ateom-gvisorWorker Pod 内的小助手暴露RunWorkload、CheckpointWorkload、RestoreWorkload三个 gRPC 接口是真正执行runsc子命令的地方源码在 cmd/ateom-gvisor/main.go。runscgVisor 的命令行运行时负责 create/start/pause/resume/checkpoint/restore 等底层操作封装在 cmd/ateom-gvisor/runsc.go。这种分层让物理 Pod 的生命周期与沙箱内 Agent 进程的生命周期彻底解耦Pod 可以反复擦除复用Actor 的状态则随快照在存储里长存、随时“复活”到集群里任意一台 Worker。三、Checkpoint 原理一次快照如何诞生CheckpointWorkload的处理逻辑是理解 gVisor 后端的核心它按**快照作用域Snapshot Scope**分两条路径3.1 Full 作用域进程内存 数据卷全带走对沙箱的pause 容器根容器执行runsc checkpoint -image-path 目录把整个沙箱进程树内存、文件、网络状态写入镜像文件checkpoint.img及可能的分页文件。如果 Actor 声明了DurableDir持久卷再把卷目录tar 成durable-tar放进同一快照目录见 cmd/ateom-gvisor/durable.go并自动跳过 gVisor 内部的.gvisor.*文件与遗留 socket。完成后清理 runsc 容器记录把“runsc 实际写了哪些文件”如实报告给 atelet由它上传到对象存储。3.2 Data 作用域只保存数据不保存内存先runsc pause冻结沙箱保证 tar 出来的文件处于一致状态tar 完持久卷后必须立即runsc resume——源码里特意用context.WithoutCancel兜底防止调用方超时导致沙箱永远停在暂停状态这是个非常贴心的防御性设计。Data 快照体积小得多适合“只关心应用数据”的轻量持久化场景。两种作用域的差异与“Golden Snapshot黄金快照”的概念完整定义在 docs/glossary.md 的 Snapshots 一节。四、Restore 原理如何在任意 Worker 上瞬间复活恢复发生在 RestoreWorkload 中atelet 事先已把快照下载到磁盘ateom 只需做四步解压持久卷若有DurableDir把快照中的 tar 解回 Actor 的宿主目录并清理.gvisor.*残留。组装 rootfs用节点镜像缓存叠出 overlay只读镜像层 Actor 私有 upper这一步是 ateom 的职责因为 atelet 没有挂载权限。create restore先runsc createpause 容器再runsc restore -image-path 快照目录 -background -detach从快照恢复沙箱随后对每个应用容器用同一份 checkpoint 执行 restore注释写得很直白“只对根容器拍快照但每个容器都要 restore”。就绪 接网轮询各容器的 readyz 端点直到全部 200再激活 Actor 网络ingress 隧道 egress 网关Actor 即刻对外服务。 因为 TCP 监听器状态就在快照的 RAM 里resume 后 readyz 通常一次探测即通过几乎没有额外延迟。Restore 的几个关键细节--cpu-num-from-quotacreate 和 restore 都带上此参数让恢复出的 Sentry 按 cgroup CPU 配额定 vCPU 数而不是默认“吃满宿主全部 CPU”见 runsc.go。cgroup 委派启动时 ateom 会把 Worker 自身进程挪进ateom叶子 cgroup把控制器开放给 runsc 嵌套建容器保证每个容器有真实的 CPU/内存/PID 记账见 main.go。-allow-connected-on-saverunsc start时固定携带用于绕过 gVisor checkpoint 后网络连接恢复的已知 bug这也是官方文档特别注明的 gVisor 后端要求。串行化锁所有跑 runsc 的 gRPC 共用一把可取消互斥锁杜绝并发 checkpoint/restore 互相踩踏。五、与冷启动的对比恢复到底快在哪维度冷启动RunWorkload快照恢复RestoreWorkload进程状态从镜像全新拉起从 RAM 镜像精确还原就绪时间取决于应用启动逻辑亚秒级系统指标ate.actor.restore.duration可观测网络监听应用自行 bind监听器状态在快照内存中直接可用典型场景Actor 首次运行 / Data 快照重复 Resume 的常见路径冷启动时RunWorkload的流程是create start pause 容器 → 逐个 create start 应用容器 → 等 readyz → 接网与恢复路径共用同一套网络与 rootfs 组装逻辑。六、动手体验在 kind 集群上跑起来想亲手验证这套机制最快路径是本地 kind 开发环境步骤摘自 README.md安装 Go、kubectl、docker执行hack/create-kind-cluster.sh建集群hack/install-ate-kind.sh --deploy-ate-system装 Substrate 系统hack/install-ate-kind.sh --deploy-demo-counter部署 Counter 演示go install ./cmd/kubectl-ate然后kubectl ate create actor my-counter-1 -a ate-demo-counter --template counter创建 Actor端口转发到路由网关节点curl一下计数器即可看到“请求触发 resume → 计数器保持连续”的完整效果。gVisor 沙箱的具体镜像与 runsc 版本由集群级SandboxConfig指定参考 manifests/ate-install/sandboxconfig-gvisor.yaml 和 docs/api-guide.md 的 SandboxConfig 章节ActorTemplate、WorkerPool 的完整配置见 cmd/ateom-gvisor/ 与 docs/api-guide.md。七、小结gVisor 后端的本质把runsc的 checkpoint/restore 包装成 Actor 生命周期的“休眠/唤醒”实现状态与物理节点解耦。checkpoint 两条路Full进程内存 rootfs 增量 DurableDir tar与 Datapause → tar 卷 → resume按需选择成本。restore 四步曲解卷 → 叠 rootfs → create restore → readyz 就绪接网全程亚秒级。工程细节见真章--cpu-num-from-quota、cgroup 委派、-allow-connected-on-save、可取消互斥锁每一个都在为“高密度、高可靠”铺路。理解了这个后端你就理解了 Agent Substrate 为什么敢承诺“百万级沙箱、10 倍密度”——因为状态可以随时搬走而搬走和搬回来的成本只有一份快照的距离。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考