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

在最近的一篇文章中，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/