Modal 破解 Kubernetes 限制，在几秒内扩展 100 万个并发沙箱

AI摘要 Modal 工程师为支撑百万级并发沙箱与万级每秒创建吞吐，自研沙箱基础设施，放弃 Kubernetes 等强一致性编排系统。核心在于规避 O(N) 状态协调瓶颈，将所有高复杂度组件设计为水平可扩展，极致简化沙箱创建路径。

关键观点：传统容器平台因 etcd 强一致性和 O(N) 调度复杂度难以扩展至百万沙箱；etcd 缺乏键空间分片能力，高 Pod 创建/更替率下易成瓶颈；沙箱系统设计优先级是水平扩展性与创建路径极简性。

适合云原生平台工程师、大规模调度系统架构师、Serverless 基础设施开发者阅读。

在最近的一篇文章中，Modal 工程师 Colin Weld 和 Connor Adams 介绍了他们 如何从头重建沙箱基础设施 ，以支持数百万个并发沙箱以及每秒数万次沙箱创建。

据 Weld 和 Adams 介绍，Kubernetes 等传统容器编排系统难以在这种规模下运行，因为它们高度依赖集中式协调和强一致性状态。

运行 100 万个沙箱对于任何容器平台的极限都是个考验，这既是因为容器数量庞大，也是因为运行如此多的沙箱需要数万个计算节点。其中许多操作的复杂度要么是 O(容器数)，要么是 O(节点数)，或是两者兼而有之，这将导致传统容器平台达到扩展极限。

他们解释说，以 Kubernetes 为例，调度算法和中央持久化存储（etcd）的负载都会随着节点和 Pod 数量的增加而增长。此外，Pod 和节点都会多次向 etcd 写入数据，“这在 Pod 创建率很高或 Pod 更替率很高时可能会引发严重的问题，而且 etcd 没有为在同一个键空间内进行分片提供原生支持”。他们还指出，克服这一限制是可行的，但需要做“大量的工作”，包括重写或替换 etcd 以及对调度算法进行并行化处理。

为了优化可扩展性，我们决定：所有产生 O(沙箱) 或 O(节点) 级负载的组件都必须默认支持水平扩展；沙箱创建流程应尽可能简单；其余事项则应视为次要。

Modal 工程师对其平台做出的根本性改动是停止全局协调，使调度更接近于负载均衡。每个工作节点不再依赖于中央数据存储作为“单一数据源”，而是各自成为自己的“单一数据源”。同样，他们没有使用单个的串行调度器，而是部署了一组并行运行的调度服务器，从而使调度层能够实现水平扩展。

一旦调度服务器决定在哪个工作节点上创建沙箱，它就会通过 RPC 直接联系该工作节点，请求创建沙箱。如果工作节点有空闲资源，就会接受调度请求；否则则拒绝该请求。

据他们介绍，最终形成的架构仅有一个瓶颈：所有工作进程都会将状态发布到一个 Redis 流中。不过，“负载测试表明，这种方案在工作进程的数量远超 10 万时仍然可行”。在基准测试中，他们在不到一分钟的时间内创建了 100 万个沙箱，从启动到运行代码的中位时间不到 0.5 秒。

在 LinkedIn 上，Hopsworks 首席执行官 Jim Dowling 在评论该公告时 指出 ，“规模每增加一个数量级，就会出现新的技术问题”，这表明该团队必须对设计进行多次迭代，才能实现每秒可靠地创建 5 万个沙箱的目标。更有实质意义的是，亚马逊云科技首席 AI 工程师 Alex Jones 指出，Modal 取得这一成果的关键在于， 他们并未试图扩展 Kubernetes ，而是在理解其局限性后“绕过了整个系统”。Jones 认为，这是“首个可信的信号，表明 Kubernetes 未能足够快速地适应生成式 AI 基础设施的实际需求”，并指出：

我们正朝着协调与执行脱钩的方向发展。执行层需要的是 Modal 的实现：能在几毫秒内建立起隔离边界。而协调层（多代理工作流需要共享内存，并且存在安全边界重叠）仍然需要 Kubernetes 这类系统所擅长的功能。

Modal 是一个专为 AI 工作负载打造的无服务器计算平台，提供对 CPU、GPU、容器、推理、训练、批处理任务以及隔离沙箱的可编程访问。它并非唯一一个试图围绕高可扩展基础设施和 10 毫秒内完成冷启动这两个目标来“重构云”的平台。其他追求类似目标的项目还有 Unikraft 、 Google Substrate 和 Overdrive 。

原文链接： https://www.infoq.com/news/2026/09/modal-scaling-sandboxes/