控制面宕机为何不影响沙箱CubeSandbox 控制面与数据面分离设计详解【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandboxCubeSandbox 是一套面向 AI Agent 的极速安全沙箱服务基于 RustVMM KVM 在数十毫秒内启动硬件隔离的 MicroVM。它的核心架构决策之一就是控制面与数据面的彻底分离调度、API 网关等控制面组件全部宕机时已经运行中的沙箱依然正常处理流量——这正是生产集群敢于长时间稳定运行的底气。本文带你搞懂这套设计背后的 4 个关键机制。一张表看懂谁在控制面谁在数据面层组件职责部署形态控制面CubeAPI、CubeMaster、CubeOps、WebUIAPI 网关、调度、节点管理、运维控制台集中部署无状态可多副本数据面Cubelet、CubeShim、CubeHypervisor、CubeCoW、CubeVS、CubeEgress、CubeProxyVM 生命周期、存储、网络、安全策略、请求路由节点本地常驻每计算节点一套共享状态Redis沙箱元数据与生命周期事件的唯一可信源独立部署一句话总结控制面是大脑负责决策数据面是四肢负责干活。大脑短暂失聪四肢照样能跑。控制面宕机时数据面为什么还能继续工作1️⃣ 沙箱创建完成后控制面就退出群聊了一次Sandbox.create()调用中控制面CubeAPI → CubeMaster只参与调度与分发选节点、通知 Cubelet 创建沙箱、把生命周期事件写入 Redis。沙箱一旦跑起来所有运行期流量都不再经过控制面客户端访问沙箱服务的请求走 CubeProxy 直接路由到计算节点上的 MicroVM沙箱出站的网络流量由节点上的 CubeVSeBPF和 CubeEgress 处理。也就是说控制面宕机不会卡住任何在途请求。2️⃣ eBPF 内核数据面线速转发零进程依赖CubeVS 把 SNAT/DNAT、连接追踪、网络策略全部实现为挂载在内核关键路径上的 BPF 程序在内核态以线速执行。它不是用户态进程控制面进程死活与它毫无关系——只要宿主机内核在网络转发就在。3️⃣ CubeProxy 本地路由缓存Redis 不可达也不掉流量CubeProxyOpenResty Lua路由沙箱请求所需的元数据HostIP、SandboxIP、端口映射等会镜像到 nginx 共享内存缓存中见 backend_cache.lua。即使 Redis 与控制面短暂失联代理也能用本地缓存继续命中路由新沙箱的元数据则等控制面恢复后自动补齐。4️⃣ 自动暂停/恢复由独立的生命周期管理器接管cube-lifecycle-manager 是一个独立于控制面主链路的服务专职监听 Redis 生命周期事件流、自动暂停空闲沙箱、并在请求到达时透明恢复。在 K8s 部署中它默认双副本 Redis 选主两个副本都消费事件、都能处理恢复请求只有 leader 执行空闲清扫——单个副本故障不中断自动暂停/恢复能力。控制面自己怎么保证高可用数据面不怕控制面挂控制面自身也尽量挂不死彻底无状态CubeAPI 与 CubeMaster 不保存任何本地状态Redis 是唯一可信源。任意实例可处理任意请求横向扩容就是加副本见 架构概览。v0.7.0 控制面与运维分离节点管理等运维能力从 CubeMaster 拆出独立为 CubeOps默认双副本部署v0.7.0 发布说明。调度归 CubeMaster、运维归 CubeOps职责边界清晰互不拖累。多副本 CubeProxy 实时发现CubeProxy 通过 Redis 注册表互相发现扩展副本零静态配置。诚实说边界控制面挂了一定范围的影响控制面宕机期间场景是否受影响运行中沙箱处理流量❌ 不受影响自动暂停 / 自动恢复✅ 基本不受影响独立管理器双副本新建沙箱、销毁、暂停⚠️ 暂时不可用恢复后自动可用沙箱列表查询 / WebUI 管理⚠️ 暂时不可用控制面恢复后无状态组件直接重连 Redis 即可继续服务不需要任何数据修复——这正是不把状态放本地的回报。多机集群中的分工在多机部署中控制节点跑全套技术栈CubeMaster、CubeOps、CubeAPI、CubeProxy、MySQL、Redis计算节点只跑节点本地组件 Cubelet network runtime并向控制面注册。控制节点整体故障时各计算节点上的数据面同样自洽运行存量沙箱流量不受波及。小结CubeSandbox 的控制面宕机不影响运行中沙箱不是口号而是四个设计叠加的结果数据面节点本地常驻、eBPF 内核态线速转发、CubeProxy 本地路由缓存、独立的生命周期管理器。控制面负责聪明数据面负责健壮——这是它能支撑大规模 Agent 并行跑分、持续迭代升级的架构根基。延伸阅读架构总览docs/zh/architecture/overview.mdCubeVS 网络模型docs/zh/architecture/network.md沙箱生命周期自动暂停/恢复docs/zh/guide/lifecycle.md多机集群部署指南docs/zh/guide/multi-node-deploy.md核心组件源码CubeAPI/、CubeMaster/、CubeOps/、CubeShim/、hypervisor/【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 控制面宕机为何不影响沙箱？CubeSandbox 控制面与数据面分离设计详解
控制面宕机为何不影响沙箱CubeSandbox 控制面与数据面分离设计详解【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandboxCubeSandbox 是一套面向 AI Agent 的极速安全沙箱服务基于 RustVMM KVM 在数十毫秒内启动硬件隔离的 MicroVM。它的核心架构决策之一就是控制面与数据面的彻底分离调度、API 网关等控制面组件全部宕机时已经运行中的沙箱依然正常处理流量——这正是生产集群敢于长时间稳定运行的底气。本文带你搞懂这套设计背后的 4 个关键机制。一张表看懂谁在控制面谁在数据面层组件职责部署形态控制面CubeAPI、CubeMaster、CubeOps、WebUIAPI 网关、调度、节点管理、运维控制台集中部署无状态可多副本数据面Cubelet、CubeShim、CubeHypervisor、CubeCoW、CubeVS、CubeEgress、CubeProxyVM 生命周期、存储、网络、安全策略、请求路由节点本地常驻每计算节点一套共享状态Redis沙箱元数据与生命周期事件的唯一可信源独立部署一句话总结控制面是大脑负责决策数据面是四肢负责干活。大脑短暂失聪四肢照样能跑。控制面宕机时数据面为什么还能继续工作1️⃣ 沙箱创建完成后控制面就退出群聊了一次Sandbox.create()调用中控制面CubeAPI → CubeMaster只参与调度与分发选节点、通知 Cubelet 创建沙箱、把生命周期事件写入 Redis。沙箱一旦跑起来所有运行期流量都不再经过控制面客户端访问沙箱服务的请求走 CubeProxy 直接路由到计算节点上的 MicroVM沙箱出站的网络流量由节点上的 CubeVSeBPF和 CubeEgress 处理。也就是说控制面宕机不会卡住任何在途请求。2️⃣ eBPF 内核数据面线速转发零进程依赖CubeVS 把 SNAT/DNAT、连接追踪、网络策略全部实现为挂载在内核关键路径上的 BPF 程序在内核态以线速执行。它不是用户态进程控制面进程死活与它毫无关系——只要宿主机内核在网络转发就在。3️⃣ CubeProxy 本地路由缓存Redis 不可达也不掉流量CubeProxyOpenResty Lua路由沙箱请求所需的元数据HostIP、SandboxIP、端口映射等会镜像到 nginx 共享内存缓存中见 backend_cache.lua。即使 Redis 与控制面短暂失联代理也能用本地缓存继续命中路由新沙箱的元数据则等控制面恢复后自动补齐。4️⃣ 自动暂停/恢复由独立的生命周期管理器接管cube-lifecycle-manager 是一个独立于控制面主链路的服务专职监听 Redis 生命周期事件流、自动暂停空闲沙箱、并在请求到达时透明恢复。在 K8s 部署中它默认双副本 Redis 选主两个副本都消费事件、都能处理恢复请求只有 leader 执行空闲清扫——单个副本故障不中断自动暂停/恢复能力。控制面自己怎么保证高可用数据面不怕控制面挂控制面自身也尽量挂不死彻底无状态CubeAPI 与 CubeMaster 不保存任何本地状态Redis 是唯一可信源。任意实例可处理任意请求横向扩容就是加副本见 架构概览。v0.7.0 控制面与运维分离节点管理等运维能力从 CubeMaster 拆出独立为 CubeOps默认双副本部署v0.7.0 发布说明。调度归 CubeMaster、运维归 CubeOps职责边界清晰互不拖累。多副本 CubeProxy 实时发现CubeProxy 通过 Redis 注册表互相发现扩展副本零静态配置。诚实说边界控制面挂了一定范围的影响控制面宕机期间场景是否受影响运行中沙箱处理流量❌ 不受影响自动暂停 / 自动恢复✅ 基本不受影响独立管理器双副本新建沙箱、销毁、暂停⚠️ 暂时不可用恢复后自动可用沙箱列表查询 / WebUI 管理⚠️ 暂时不可用控制面恢复后无状态组件直接重连 Redis 即可继续服务不需要任何数据修复——这正是不把状态放本地的回报。多机集群中的分工在多机部署中控制节点跑全套技术栈CubeMaster、CubeOps、CubeAPI、CubeProxy、MySQL、Redis计算节点只跑节点本地组件 Cubelet network runtime并向控制面注册。控制节点整体故障时各计算节点上的数据面同样自洽运行存量沙箱流量不受波及。小结CubeSandbox 的控制面宕机不影响运行中沙箱不是口号而是四个设计叠加的结果数据面节点本地常驻、eBPF 内核态线速转发、CubeProxy 本地路由缓存、独立的生命周期管理器。控制面负责聪明数据面负责健壮——这是它能支撑大规模 Agent 并行跑分、持续迭代升级的架构根基。延伸阅读架构总览docs/zh/architecture/overview.mdCubeVS 网络模型docs/zh/architecture/network.md沙箱生命周期自动暂停/恢复docs/zh/guide/lifecycle.md多机集群部署指南docs/zh/guide/multi-node-deploy.md核心组件源码CubeAPI/、CubeMaster/、CubeOps/、CubeShim/、hypervisor/【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考