什么是 Node、集群与调度
一句话定义
CubeSandbox 不是只在一台机器上“跑沙箱”的工具，而是一个可以扩展成多节点系统的平台。
在这个平台里：
- Node 是实际承载 Sandbox 的计算节点
- Cluster 是由多个节点与控制面组成的整体系统
- Scheduling 是把一个创建请求分配到某个具体节点上的过程
这三个概念共同决定 CubeSandbox 的伸缩方式和平台形态。
为什么必须把这三个概念分开
如果只看单机体验，很容易误以为 CubeSandbox 的核心就是：
- 一个 API
- 一台机器
- 若干个沙箱
但只要系统开始追求：
- 更高容量
- 更高可用性
- 更稳定资源利用率
- 不同工作负载分布到不同机器
就一定会出现三个问题：
- 哪台机器来承载这个实例？
- 谁来掌握整个系统的资源视图？
- 节点和控制面各自负责什么？
于是 Node、Cluster 和 Scheduling 就成为不可回避的核心概念。
什么是 Node
定义
Node 是实际承载 Sandbox 实例的计算节点。
它通常具备：
- KVM 与底层虚拟化能力
- 本地运行时资产
- 节点本地调度与生命周期管理组件
- 本地网络与存储执行能力
在 CubeSandbox 里的真实角色
Node 不是“被动机器”，而是执行面主体。
它负责真正把一个抽象请求变成活的实例，包括：
- 准备 Sandbox 运行时资产
- 创建 / 恢复实例
- 维护本地网络
- 管理实例状态
- 回收实例与本地资源
所以 Node 可以理解成：
控制面意图真正落地的地方。
为什么 Node 不是控制面
Node 知道“如何执行”，但它通常不应该独自决定“整个系统如何调度”。
这就是为什么需要 Cluster 和控制面。
什么是 Cluster
定义
Cluster 是由控制面和多个 Node 共同构成的 CubeSandbox 整体。
它的意义不是“机器多了”，而是系统开始拥有了全局视角：
- 哪些节点可用
- 哪些节点资源充足
- 哪些实例在哪些节点上
- 模板和实例元数据如何统一管理
Cluster 真正解决什么问题
Cluster 解决的是 全局协调问题。
单机时，很多问题可以省略：
- 调度目标只有一个
- 资源视图天然本地化
- 状态一致性更简单
多机时，这些假设全部失效，平台必须引入控制面视角来维持：
- 全局资源认知
- 请求分发
- 节点注册与健康
- 实例与模板元数据统一
为什么 Cluster 不是“多台机器的总称”
如果只是多台机器但没有统一控制与调度，它只是机器集合，不是平台级 Cluster。
Cluster 的本质在于：
系统开始以“整体”而不是“单机脚本”方式组织计算能力。
什么是 Scheduling
定义
Scheduling（调度）是控制面根据某种规则，把一个 Sandbox 创建请求分配给某个 Node 的过程。
调度到底在决定什么
调度不是简单“随机选台机器”，而是在回答：
- 哪台机器当前更适合承载这个 Sandbox
- 该实例所需资源在哪个节点上更容易满足
- 是否有模板、网络、节点标签或策略上的约束
- 整个系统如何保持容量平衡与稳定性
为什么调度是平台灵魂之一
一个平台的好坏，很大程度上体现在调度是否正确：
- 调度正确，系统更稳定、更高效
- 调度错误，单机再强也会出现热点、资源碎片和失败抖动
CubeSandbox 中控制面与节点面的边界
这是理解 Node / Cluster 的关键。
控制面更关心“意图与全局”
控制面主要负责：
- 接收外部 API 请求
- 维护模板与实例元数据
- 感知节点状态
- 选择调度目标
- 定义全局策略与系统视图
控制面主要回答的是：
“应该做什么、在哪做、系统整体现在怎样？”
节点面更关心“执行与本地状态”
节点面主要负责：
- 真正启动或恢复 Sandbox
- 维护本地运行时与网络
- 跟踪本地实例状态
- 处理回收、清理、重建等动作
节点面主要回答的是：
“这件事在本机怎么做，当前做到了哪一步？”
为什么这个边界必须清晰
如果控制面管得太细，会失去伸缩性； 如果节点面过于自治，又会丢掉全局协调能力。
所以健康的平台通常遵循：
- 控制面做全局决策
- 节点面做本地执行
CubeSandbox 的整体设计也符合这个方向。
一次请求如何穿过这三层概念
可以把一次 Sandbox 创建简化成下面的思路：
- 用户向控制面发起请求
- 控制面解析请求涉及的 Template、规格和策略
- 调度逻辑选择一个合适的 Node
- 该 Node 的本地组件开始实例化 Sandbox
- 节点反馈状态给控制面
- 控制面把最终可访问结果返回给用户
这条链路说明：
- 请求是全局进入的
- 实例是本地落地的
- 调度是中间的桥梁
Node 视角下最重要的本地职责
如果你从节点视角看，真正关键的不是“自己是集群成员”这一身份，而是它要承接的本地职责。
1. 本地生命周期管理
节点必须能可靠地：
- 创建实例
- 查询实例状态
- 回收实例
- 恢复必要状态
2. 本地资源管理
节点要知道本机有哪些资源可用于 Sandbox：
- CPU / 内存
- 本地网络对象
- 本地存储空间
- 运行时 socket 与目录
3. 本地故障吸收
一个稳定平台不应该把所有小故障都放大成全局事故。
节点需要尽量在本地处理：
- 清理失败实例
- 回收损坏状态
- 重建本地运行时关联
Cluster 视角下最重要的全局职责
如果你从 Cluster 视角看，最重要的是保持“全局一致认知”。
1. 节点健康认知
系统需要知道：
- 哪些节点在线
- 哪些节点可调度
- 哪些节点资源不足
- 哪些节点应被摘除或降级
2. 实例位置认知
控制面需要知道某个 Sandbox 当前在哪个节点，否则就无法：
- 查询状态
- 路由请求
- 做后续运维
3. 资源分布认知
调度不是一次性动作，而是持续依赖全局资源视图。
调度到底以什么为依据
具体算法可以演进，但概念上通常会参考以下维度：
- 节点可用性
- 剩余资源
- 节点标签或角色
- 模板或运行时依赖
- 网络与访问路径要求
- 平衡策略与热点规避
所以调度不是“选一个节点”，而是“在多个约束和优化目标之间做选择”。
为什么多节点能力对 CubeSandbox 很关键
CubeSandbox 的一个核心价值是：
- 单节点上可以高密度运行大量 Sandbox
- 同时又可以扩展到多节点集群
这意味着它既要有 单机高密度能力，也要有 集群扩展能力。
如果没有 Node / Cluster / Scheduling 这套概念，系统就只能停留在“单机演示很强”的阶段，无法真正成为平台。
常见误解
误解一：既然单机能跑很多实例，集群调度就没那么重要
不对。
单机高密度解决的是单节点效率；集群调度解决的是整体容量和分布问题。两者不是替代关系。
误解二：调度就是控制面决定完，节点只照做
不完全对。
控制面决定目标节点，但节点面仍然承担大量实际可执行性判断与本地状态处理。没有强节点执行能力，调度只是一纸命令。
误解三：Node 只是“安装了 Cubelet 的机器”
不够准确。
Node 是平台运行时能力、网络能力、存储能力和本地生命周期能力的实际承载者，而不只是装了一个进程的机器。
对运维和平台设计的意义
如果你是运维或架构角色，理解这组概念时最该抓住的是：
- Cluster 决定平台上限。
- Node 决定实例落地质量。
- Scheduling 决定资源分布与体验稳定性。
很多线上问题最后都可以归结到这三层之一：
- 调度选错节点
- 节点本地状态不健康
- 控制面对全局状态认知不完整
和相关文档的关系
- 想看控制面与组件概览： 架构概览
- 想看节点配置与运行时路径： 节点与运行时配置文件路径与说明
- 想看控制面配置： 控制面配置文件路径与说明
- 想看网络概念： 什么是网络、暴露端口与访问路径
下一步
理解了实例被谁承载、如何调度之后，下一个问题通常是：
这些 Sandbox 创建出来后，到底如何联网、如何暴露服务、外部又是怎么访问进去的？
这就进入网络概念： 什么是网络、暴露端口与访问路径。