Cube Sandbox

简体中文

English

简体中文

English

Appearance

什么是网络、暴露端口与访问路径 ​

一句话定义 ​

在 CubeSandbox 中，网络不是“实例启动后顺便给一张网卡”，而是 Sandbox 可用性的关键组成部分。

这一组概念主要回答三件事：

  • Sandbox 是否能访问外部网络
  • 外部如何访问 Sandbox 内部服务
  • 平台如何在隔离前提下完成这些连接

为什么网络在 CubeSandbox 里是核心概念 ​

很多人会先把 CubeSandbox 看成“安全执行代码的环境”，于是容易低估网络的重要性。

但现实场景里，一个可用的 Agent Sandbox 往往需要：

  • 访问外部 API
  • 下载依赖与模型资源
  • 打开浏览器访问网站
  • 对外暴露 HTTP / WebSocket / 调试端口
  • 在平台路由下被 SDK 或代理访问

如果网络只是附属功能，CubeSandbox 就只能停留在“本地 shell 沙箱”。

CubeSandbox 之所以是平台而不是命令执行器，关键之一就在于它把网络也纳入了 Sandbox 的正式抽象。

先分清三层网络问题 ​

理解 CubeSandbox 网络，最重要的是先把三个问题拆开。

1. Sandbox 出站网络 ​

即：Sandbox 能不能主动访问外部世界。

例如：

  • pip install
  • 请求外部 API
  • 浏览器访问公网

2. Sandbox 入站访问 ​

即：外界如何访问 Sandbox 内部服务。

例如：

  • 外部访问 Guest 中的 HTTP 服务
  • SDK 连接某个暴露端口
  • 平台把域名 / 端口路由到正确实例

3. 平台内部网络隔离 ​

即：平台如何保证一个 Sandbox 的网络行为不会天然影响另一个 Sandbox，且不能任意探测宿主机和内网。

CubeSandbox 真正有价值的，不是单独解决其中某一个，而是把三者同时纳入统一模型。

什么是 Sandbox 网络视角 ​

每个 Sandbox 并不是直接“共享宿主机网络”，而是拥有自己的虚拟网络视角。

这意味着从实例内部看：

  • 它看到的是自己的虚拟接口
  • 它拥有自己的内部地址语义
  • 它的出站和入站都要经过平台编排

这层设计非常重要，因为它决定了：

  • 隔离可以成立
  • 网络策略可以落在实例粒度
  • 路由和暴露可以和平台元数据绑定

为什么 CubeSandbox 不能直接复用“传统容器网络思路” ​

传统容器网络在很多场景够用，但 CubeSandbox 的目标更苛刻：

  • 每个实例是强隔离 Guest
  • 实例数量密度高
  • 网络路径要足够轻
  • 需要实例级安全策略
  • 需要和端口暴露 / 域名访问紧密配合

因此 CubeSandbox 把网络设计成平台核心子系统，而不是简单依赖一套通用 bridge / iptables 拼装。

什么是 CubeVS ​

在 CubeSandbox 的语境里，CubeVS 是负责实现节点侧沙箱网络虚拟化与隔离能力的关键子系统。

它的核心目标不是“提供一张虚拟网络”，而是：

  • 给每个 Sandbox 提供独立网络接入点
  • 在内核态完成高性能转发与策略控制
  • 支持出站访问、入站映射和隔离策略

如果把 Sandbox 看成“计算对象”，那么 CubeVS 可以理解成这些计算对象的“网络平面”。

更底层的实现细节见 CubeVS 网络模型。

什么是暴露端口（Exposed Port） ​

定义 ​

暴露端口指的是：

平台承认某个 Guest 内服务端口应当被外部访问路径看见，并为它建立相应映射或路由。

为什么暴露端口是平台概念而不是 Guest 概念 ​

Guest 内部随便监听一个端口，并不意味着外部就能访问到它。

只有当平台：

  • 记录它
  • 建立映射
  • 把它纳入代理和路由逻辑

它才真正成为“可访问服务入口”。

因此暴露端口不是单纯的 socket 事实，而是平台层的发布语义。

什么是 Probe / Ready 端口 ​

一个环境“能启动”和“可服务”不是一回事。

CubeSandbox 在模板或实例层面常常需要一个准备就绪判断依据，而端口探针就是常见手段之一。

它解决什么问题 ​

它告诉平台：

  • Guest 已经不是单纯 boot 完了
  • 真正需要交付给用户的服务已经 ready
  • 现在适合把这个 Sandbox 当成可用实例暴露出去

为什么这对 Agent 场景重要 ​

Agent 场景常常不是拿到一个 shell 就结束，而是希望环境内某个服务已经准备好了，例如：

  • 代码解释器服务
  • 浏览器控制服务
  • 自定义 API 端口

因此 Probe 是“交付语义”的重要组成部分。

外部访问路径是如何成立的 ​

从高层概念看，外界访问 Sandbox 通常要经过三步。

1. 平台知道这个实例要暴露什么 ​

这通常来自 Template 定义或实例元数据。

2. 节点网络子系统建立到正确 Guest 的映射 ​

这一步是节点侧网络执行逻辑完成的，包括端口映射与实例识别。

3. 代理 / 域名 / API 路由把请求送到正确实例 ​

这是更靠近用户入口的一层，决定“用户到底用什么地址访问到这个 Sandbox”。

也就是说，能访问一个 Sandbox，不只是它监听了端口，而是：

控制面元数据、节点网络映射和入口代理路由三者共同成立。

为什么域名解析和反向代理也属于这个概念族 ​

很多用户第一次接触时会觉得：

  • CoreDNS 是独立话题
  • CubeProxy 是独立话题
  • 端口暴露是另一话题

但从概念层看，它们其实共同回答的是同一个问题：

“用户请求是如何从平台入口，被送到某个具体 Sandbox 服务上的？”

因此：

  • DNS 解决的是“名字如何指向入口”
  • Proxy 解决的是“入口如何识别目标实例并转发”
  • 暴露端口解决的是“实例内哪个服务应被视为可访问端点”

把这三者分开看，会看不懂整个访问路径。

出站网络策略为什么也是核心概念 ​

在安全沙箱场景里，“能联网”不是默认合理答案，真正重要的是：

  • 能不能联网
  • 能访问哪些地址
  • 哪些网段必须被拒绝
  • 是否允许公网访问

这说明网络在 CubeSandbox 里不是单纯连接能力，而是 安全策略面的一部分。

从概念上说，平台通常要能做到：

  • 对每个 Sandbox 单独施加出站控制
  • 阻止访问宿主机与敏感内网
  • 允许少量白名单例外

这也是 CubeVS 价值的重要来源之一。

访问路径里的“平台入口”和“实例入口”有什么区别 ​

平台入口 ​

平台入口是用户首先接触到的地址，例如：

  • API 地址
  • 代理入口
  • 域名入口

它是平台级的。

实例入口 ​

实例入口是最终落到具体 Sandbox 的服务端口或服务地址。

它是实例级的。

CubeSandbox 的一个关键任务，就是把平台入口正确地映射到实例入口。

为什么说网络概念和调度概念是连着的 ​

一个 Sandbox 被调度到哪个 Node，不只是计算资源问题，也会影响网络路径：

  • 入口最终要找到这个 Node
  • 节点要建立到该实例的正确路由
  • 代理和域名路径要指向实际实例位置

所以网络不是调度之后才“附加”的，而是从实例落点开始就已经绑定的一部分。

常见误解 ​

误解一：Guest 能 curl 外网，就说明网络问题都解决了 ​

不对。

出站访问只是网络能力的一部分。你还需要知道：

  • 是否受策略限制
  • 外界能否访问 Guest 服务
  • 平台入口是否正确映射
  • 是否存在隔离与安全边界问题

误解二：监听端口就等于对外发布服务 ​

不对。

监听是 Guest 内部事实；发布是平台外部语义。两者之间还差一整层映射与路由。

误解三：DNS / Proxy / 端口映射是三个互不相关的小功能 ​

不对。

它们共同构成了 CubeSandbox 的“服务可达性模型”。

运维和架构视角最该关注什么 ​

如果你是平台或运维角色，理解这个概念时最该抓住四个问题：

  1. Sandbox 默认能否出网？
  2. 哪些服务端口会被平台识别为可访问入口？
  3. 请求是如何从域名 / 代理入口落到具体实例上的？
  4. 网络隔离和策略控制具体落在哪一层？

和其它文档的关系 ​

下一步 ​

理解了网络路径之后，另一个最常混淆的概念族就是：

镜像、文件系统、模板、可写层到底分别是什么？

下一章专门把这些层次拆清楚： 什么是文件系统、镜像与可写层。