CubeMaster 调度器配置完全指南节点选择流程、评分器与多机部署实战【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox本指南以 CubeSandbox 的 CubeMaster 调度器配置参考 为骨架完整讲解 CubeMaster scheduler 的配置入口、节点选择四步流程、Cubelet 上报数据如何参与调度以及在 one-click / Terraform 部署中如何把节点数量、资源配额、并发和模板副本管理配置到位。读完本文你将掌握调度评分器的权重因子与打分公式、过滤器清单、多机集群推荐配置以及调度失败、资源耗尽、节点标签不匹配和新增计算节点后模板同步的完整排查路径。如果你只想为多机部署启用基本评分可先阅读多机集群部署本文作为完整参考覆盖从配置位置到源码级原理的各个环节。配置在哪里CubeMaster 调度配置位于 CubeMaster 的conf.yaml按部署方式不同分为四个入口部署方式配置位置生效方式one-click / systemd/usr/local/services/cubetoolbox/CubeMaster/conf.yaml修改后重启cube-sandbox-cubemaster.service源码配置模板configs/single-node/cubemaster.yaml重新打包或拷贝到运行环境Tencent Cloud Terraform / TKEdeploy/one-click/terraform/tencentcloud/tke-addons.tf中的kubernetes_secret.cubemaster_conf修改 Terraform 通过yamlencode生成的配置重新 apply Terraform并重启或滚动更新 cube-master PodKubernetes / Helm chartdeploy/kubernetes/chart/files/cube-master/conf.yaml由deploy/kubernetes/chart/templates/master-config-secret.yaml渲染修改 chart 文件或渲染后的 Secret并重启或滚动更新 cube-master Pod仓库自带的单节点模板 configs/single-node/cubemaster.yaml 中scheduler段默认只启用了cpu、mem、template_locality、realtime_create_num四个过滤器priority_select_num为1、metric_update_timeout与local_metric_update_timeout为300s尚未启用任何评分器——这正是多机部署时需要重点改造的部分。Cubelet 节点元数据和资源配额不在CubeMaster 配置里而是由每台 Cubelet 上报。one-click 环境中的主要入口是配置位置说明Cubelet 静态配置/usr/local/services/cubetoolbox/Cubelet/config/config.toml包含node_status_update_frequency修改后重启 CubeletCubelet 动态配置/usr/local/services/cubetoolbox/Cubelet/dynamicconf/conf.yaml包含host.scheduler_label和host.quota修改后重启 Cubelet常见 Cubelet 动态配置示例host: scheduler_label: default-cluster quota: mcpu_limit: 0 mem_limit: mvm_limit: 0 creation_concurrent_num: 00或空值通常表示让 Cubelet 按宿主机资源推导默认值不等于无限资源。压测或大规模集群中如果要提高密度应显式评估 CPU、内存、MVM 数量和并发创建上限而不是依赖推导值兜底。CubeMaster 如何选择计算节点一次 sandbox 创建请求进入 CubeMaster 后调度大致分为四步解析请求约束读取instance_type、模板 ID、资源规格、显式 host IP、node affinity / annotations 等条件。预过滤节点排除不健康、资源上报过期、超过 MVM 上限、模板本地副本不可用、实时或本地观测创建数过高、不满足 affinity 的节点启用diskfilter 或 backoff 路径时也会排除磁盘使用过高的节点。节点评分对过滤后的候选节点计算分数例如基于mvm_num、local_create_num、quota_cpu_usage、quota_mem_usage做加权平均。最终选择从评分靠前的一组节点中选择。priority_select_num控制进入最终随机选择的高分节点数量least_select_name默认为random。从源码看过滤器与评分器均通过注册表按名称实例化过滤器注册表 中定义了cpu、mem、template_locality、realtime_create_num、disk、thirtparty六种过滤器评分器注册表 中定义了real_time_weighted_average、multi_factor_weighted_average、affinity_score、image_score四种评分器。NewSelector会逐个读取enable_filters/enable_scorers中声明的名称并通过反射调用构造函数因此配置中出现的名称必须与注册表严格一致。如果没有配置评分CubeMaster 仍会做过滤但可能按候选列表顺序选择节点导致新 sandbox 更容易集中到第一个可用节点直到资源过滤器把流量推向其他节点。关键 scheduler 字段推荐把下面的评分相关配置合并到现有cubemaster.yaml的scheduler段中。除非确实要替换否则请保留已有的filter、超时和实例类型专用配置。scheduler: # 保留当前部署已有的 filter、超时和其他 scheduler 配置。 priority_select_num: 3 score: enable_scorers: - real_time_weighted_average resource_weights: mvm_num: 2 local_create_num: 3 quota_cpu_usage: 1 quota_mem_usage: 1 plugin_conf: real_time_weighted_average: weight: 1.0 enable_weight_factors: - mvm_num - local_create_num - quota_cpu_usage - quota_mem_usage字段作用priority_select_num从评分最高的前 N 个节点中做最终选择。多节点建议大于1小集群可从3开始。metric_update_timeout节点资源指标多久未更新后视为不可调度。应明显大于 Cubelet 上报周期。local_metric_update_timeout预留的本地指标超时字段。当前 prefilter 对全局指标和本地指标的新鲜度检查都使用metric_update_timeout。filter.enable_filters启用调度过滤器。常见过滤器包括 CPU、内存、模板本地性和实时创建并发。score.enable_scorers启用评分器。多机部署通常启用real_time_weighted_average启用时必须同时配置score.plugin_conf.real_time_weighted_average否则 CubeMaster 可能在 scheduler 启动阶段 panic。score.resource_weights控制 MVM 数、创建并发、CPU/内存 quota 使用率等因子的权重。权重越高该因子对分数影响越大对应因子也必须列在score.plugin_conf.real_time_weighted_average.enable_weight_factors中。node_max_mvm_num/node_max_mvm_num_conf全局或按实例类型限制单节点 MVM 数。Cubelet 上报的max_mvm_num也会参与实际上限计算。disk_usage_max_percentdiskfilter 和 backoff 路径使用的磁盘水位阈值用于避免继续调度到快满的机器。affinityconf/node_affinity_selector_allowed_keys控制按 cluster label、zone、CPU 类型、机型等做亲和或约束选择。几点从配置解析与默认值逻辑中可以得到印证的事实见 config.gonode_max_mvm_num缺省为3000node_max_mvm_num_reserve_num_percent缺省为1.0disk_usage_max_percent缺省为80.0即磁盘使用超过 80% 即触发diskfilter 拦截priority_select_num缺省为-1metric_update_timeout与local_metric_update_timeout缺省为1h模板中显式写为300screate_concurrent_limit属于cubelet_conf段缺省为100是节点create_concurrent_num: 0时调度层的回落值。权重因子名称均定义在 constants.go除了本文示例用到的mvm_num、local_create_num、quota_cpu_usage、quota_mem_usage还支持req_cpu、req_mem、cpu_util、mem_usage、cpu_load、metric_update、metric_local_update_at、create_concurrent_limit、realtime_create_num、data_disk_usage、storage_disk_usage、sys_disk_usage、image_id、template_id等因子可按需启用。评分器源码级原理real_time_weighted_average评分器的实现位于 realtimescore.go。其NewRealTimeWeightedAverageScore构造函数在score.plugin_conf.real_time_weighted_average配置缺失时会直接panic——这就是文档强调启用评分器必须同步配置 plugin_conf的原因。评分计算分两步计算总权重遍历enable_weight_factors中每个因子从resource_weights取值累加得到totalWeight见getRealTimeTotalWeight若总权重为 0评分器直接返回空结果。逐节点打分getRealtimeWeightedAverageScore先调用getFactorWeightedAverageScore汇总已启用因子的加权分再额外叠加请求资源剩余量得分。各因子打分函数在 utils.go 中实现getMvmNumScore100 - MvmNum / MaxMvmLimit * 100节点承载的 MVM 数越接近上限得分越低getLocalCreateNumScore基于LocalCreateConcurrentLimit与健康 Master 节点数的乘积推算全局本地并发占用100 - f*100getQuotaCpuUsageScore/getQuotaMemMbUsageScore100 - EffectiveAllocated(Usage) / Quota * 100quota 使用率越高得分越低getRealTimeCreateNumScore100 - RealTimeCreateNum / CreateConcurrentNum * 100。此外若请求携带 CPU/内存资源量还会用getReciprocal计算剩余可分配量 / 总配额并乘以req_cpu/req_mem权重。每个因子的权重通过getFactorWeight从score.resource_weights读取未配置的因子权重为 0。最终得分除以总权重得到归一化分数随后priority_select_num从最高分的前 N 个节点中做随机最终选择。因此权重设置的本质是控制负载均衡倾向local_create_num权重高会强化创建并发均匀分布mvm_num权重高则倾向均匀铺开 MVM 数量quota_cpu_usage/quota_mem_usage权重高则更贴合节点真实资源水位。节点元数据如何影响调度Cubelet 会通过 CubeOps 的/internal/v1/node-agent接口注册节点并持续上报状态。CubeOps 将这些数据持久化到 MySQL/RedisCubeMaster 每隔几秒从 CubeOps 同步节点视图并维护本地缓存调度时读取最新快照sync_meta_data_interval、sync_metric_data_interval、collect_metric_interval在 cubemaster.yaml 中均默认1s。Cubelet 上报字段来源调度影响instance_typeCubelet 节点身份 / 实例类型用于匹配请求的instance_type、按类型选择模板副本、套用按类型的 MVM 配置。cluster_labelhost.scheduler_label用于 cluster label 亲和、隔离不同节点池或指定模板分发范围。quota_cpuhost.quota.mcpu_limit或宿主机推导值CPU 可调度容量参与 CPU 过滤和评分。quota_mem_mbhost.quota.mem_limit或宿主机推导值内存可调度容量参与内存过滤和评分。max_mvm_numhost.quota.mvm_limit或按内存推导单节点可承载的 MVM 数上限超过后节点会被过滤。create_concurrent_numhost.quota.creation_concurrent_num节点上报的创建并发配置。0表示 Cubelet 不设置额外 engine flow limit但 CubeMaster 调度层仍会回落到cubelet_conf.create_concurrent_limit缺省100。allocated / disk usage / cgroup metricsCubelet 周期上报用于判断当前资源使用率、磁盘水位和评分因子。这些值是每个计算节点独立配置和上报的。异构集群中不同节点可以有不同实例类型、标签、配额和并发上限。部署变量映射one-click 多节点变量 / 配置影响ONE_CLICK_DEPLOY_ROLEcompute安装计算节点只运行 Cubelet 等运行时服务并向控制面注册。CUBE_SANDBOX_NODE_IP当前节点注册到 CubeOps 的可路由地址。配置错误会导致节点不可达或不出现。ONE_CLICK_CONTROL_PLANE_IP/ONE_CLICK_CONTROL_PLANE_CUBEOPS_ADDRCubelet 注册和上报使用的 CubeOps 地址端口 3010。CubeMaster 单独监听 8089。Cubelet/config/config.toml中的node_status_update_frequency节点状态和资源上报周期。默认1s不要配置到 dynamicconf。Cubelet/dynamicconf/conf.yaml中的host.scheduler_label节点池标签用于 affinity 和隔离。Cubelet/dynamicconf/conf.yaml中的host.quota.*CPU、内存、MVM 数、创建并发等调度容量。Tencent Cloud Terraform / TKE变量影响TENCENTCLOUD_COMPUTE_NODE_COUNTPVM 计算节点数量直接决定可承载 sandbox 的节点池规模。TENCENTCLOUD_COMPUTE_INSTANCE_TYPE默认计算节点机型影响真实 CPU/内存和 Cubelet 推导出的 quota。TF_VAR_compute_instance_types逐台指定异构计算节点机型。适合压测或混部场景。TENCENTCLOUD_COMPUTE_DATA_DISK_SIZE每台计算节点/data/cubelet数据盘大小影响模板、快照和运行时数据容量。TENCENTCLOUD_CUBELET_NODE_STATUS_UPDATE_FREQUENCYTerraform 安装时写入每台计算节点的 Cubelet 静态配置控制节点状态/资源上报频率。TENCENTCLOUD_TKE_NODE_COUNT/TENCENTCLOUD_TKE_WORKER_INSTANCE_TYPE控制面 Pod 资源不直接承载 sandbox但会影响 CubeMaster、cube-api、cube-proxy 等控制面吞吐。TENCENTCLOUD_COMPUTE_NODE_COUNT和TENCENTCLOUD_TKE_NODE_COUNT是两套资源前者运行 Cubelet 并承载 sandbox后者运行控制面 Pod。扩容时不要只加 TKE 节点计算节点池才是 sandbox 的真正容量来源。推荐配置小测试集群适合 POC、功能验证和少量并发。下面是新建小测试集群可用的完整起始配置包含随项目提供的超时和过滤器默认值如果是在已有部署上调整请按需合并不要盲目替换无关的 scheduler 配置。scheduler: priority_select_num: 3 metric_update_timeout: 300s local_metric_update_timeout: 300s filter: enable_filters: - cpu - mem - template_locality - realtime_create_num score: enable_scorers: - real_time_weighted_average resource_weights: mvm_num: 2 local_create_num: 3 quota_cpu_usage: 1 quota_mem_usage: 1 plugin_conf: real_time_weighted_average: weight: 1.0 enable_weight_factors: - mvm_num - local_create_num - quota_cpu_usage - quota_mem_usage建议至少 2 台计算节点便于验证节点选择和故障隔离。priority_select_num从3开始如果计算节点少于 3 台可以设为节点数。Cubelet 上报周期保持默认1sCubeMaster 指标超时保持300s。host.quota使用默认推导值即可但压测前必须显式检查是否过低。较大生产类集群适合更高并发或长期运行按节点池设置清晰的host.scheduler_label例如通用池、内存型池、压测池避免不同用途互相挤占。为不同instance_type配置node_max_mvm_num_conf不要把大规格节点和小规格节点套同一组上限。从 config.go 可以看到node_max_mvm_num_conf按实例类型匹配未匹配的类型回落到全局node_max_mvm_num。适当增大priority_select_num通常可设置为健康计算节点数的一个小比例但不建议大到完全随机。保留template_locality过滤器确保创建只落到已有模板副本的节点。为host.quota.creation_concurrent_num设置明确上限避免镜像、磁盘或 VMM 创建在单节点上被突发流量打满。控制面也要扩容提高TENCENTCLOUD_TKE_NODE_COUNT和控制面 Pod 副本数避免 CubeMaster 或 cube-api 成为瓶颈。新增计算节点后的 template redo新增 compute node 后节点注册成功并不代表所有模板都已经在该节点可用。调度器的template_locality过滤器实现见 template_locality.go会要求目标节点具备可用模板副本否则创建请求可能失败或只调度到旧节点。对镜像构建模板新增节点后必须执行 template redo把模板副本分发/重建到新节点cubemastercli tpl redo \ --template-id tpl-id \ --node node-ip说明--node接受节点 ID 或 host IP多个节点可以重复传入--node。redo默认会等待任务完成如只提交任务可使用--detach。如果只想重做失败节点可使用--failed-only。redo 完成后再创建使用该模板的 sandbox避免调度因模板不可用失败。建议在多节点扩容流程中把 template redo 作为固定步骤安装计算节点并确认它出现在 CubeMaster 节点列表。确认该节点健康、Cubelet 资源上报正常。对需要在该节点运行的模板执行cubemastercli tpl redo --template-id tpl-id --node node-ip。等待 redo job 成功后再放开业务流量或运行 E2E。排障调度失败或返回 no more resource检查方向quota_cpu/quota_mem_mb是否低于实际创建需求。host.quota.mcpu_limit、host.quota.mem_limit、host.quota.mvm_limit是否仍为默认推导值。mvm_num是否达到max_mvm_num或node_max_mvm_num_conf上限。有效创建并发上限是否阻塞了当前节点。注意create_concurrent_num: 0在调度层仍会回落到 CubeMaster 的cubelet_conf.create_concurrent_limit。常用入口curl http://127.0.0.1:3010/internal/v1/nodes sudo tail -F /data/log/CubeMaster/cubemaster-req.log sudo tail -F /data/log/Cubelet/Cubelet-req.log节点状态或资源上报过期如果 CubeMaster 日志中出现 metric update timeout 类似信息确认计算节点cube-sandbox-cubelet.service正常运行。确认ONE_CLICK_CONTROL_PLANE_CUBEOPS_ADDR或 Terraform 生成的 CubeOps 地址从计算节点可达。检查node_status_update_frequency是否被误改得过大。确认metric_update_timeout明显大于上报周期。模板不可用典型现象是新节点加入后创建仍只落到旧节点或日志中提示模板本地副本不可用。处理确认请求使用的template_id。对新增节点执行cubemastercli tpl redo --template-id tpl-id --node node-ip。查看模板 job 状态确认 redo 成功。保留template_locality过滤器不建议为了绕过问题关闭它。Node label 不匹配如果请求设置了 node affinity、cluster label 或特定 instance type但没有候选节点检查 Cubelethost.scheduler_label是否与请求或affinityconf中的标签一致。检查instance_type是否与模板和请求匹配。检查node_affinity_selector_allowed_keys是否允许请求使用的 selector key。默认允许集合包括 zone、cluster id、CPU 类型、内存大小、CPU 核数、实例类型等键见 config.go。对异构节点池确认模板副本已经 redo 到对应标签/机型的节点。创建集中在少数节点如果多机集群中新 sandbox 仍明显集中在一台机器确认score.enable_scorers已启用。启用real_time_weighted_average时确认score.plugin_conf.real_time_weighted_average.enable_weight_factors包含预期因子。将priority_select_num设置为大于1。检查local_create_num、mvm_num、quota_cpu_usage、quota_mem_usage权重是否存在。确认各节点模板副本都可用否则template_locality会让候选节点集合变小。相关文档多机集群部署腾讯云集群部署Terraform服务管理与日志模板相关排障【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CubeMaster 调度器配置完全指南：节点选择流程、评分器与多机部署实战
CubeMaster 调度器配置完全指南节点选择流程、评分器与多机部署实战【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox本指南以 CubeSandbox 的 CubeMaster 调度器配置参考 为骨架完整讲解 CubeMaster scheduler 的配置入口、节点选择四步流程、Cubelet 上报数据如何参与调度以及在 one-click / Terraform 部署中如何把节点数量、资源配额、并发和模板副本管理配置到位。读完本文你将掌握调度评分器的权重因子与打分公式、过滤器清单、多机集群推荐配置以及调度失败、资源耗尽、节点标签不匹配和新增计算节点后模板同步的完整排查路径。如果你只想为多机部署启用基本评分可先阅读多机集群部署本文作为完整参考覆盖从配置位置到源码级原理的各个环节。配置在哪里CubeMaster 调度配置位于 CubeMaster 的conf.yaml按部署方式不同分为四个入口部署方式配置位置生效方式one-click / systemd/usr/local/services/cubetoolbox/CubeMaster/conf.yaml修改后重启cube-sandbox-cubemaster.service源码配置模板configs/single-node/cubemaster.yaml重新打包或拷贝到运行环境Tencent Cloud Terraform / TKEdeploy/one-click/terraform/tencentcloud/tke-addons.tf中的kubernetes_secret.cubemaster_conf修改 Terraform 通过yamlencode生成的配置重新 apply Terraform并重启或滚动更新 cube-master PodKubernetes / Helm chartdeploy/kubernetes/chart/files/cube-master/conf.yaml由deploy/kubernetes/chart/templates/master-config-secret.yaml渲染修改 chart 文件或渲染后的 Secret并重启或滚动更新 cube-master Pod仓库自带的单节点模板 configs/single-node/cubemaster.yaml 中scheduler段默认只启用了cpu、mem、template_locality、realtime_create_num四个过滤器priority_select_num为1、metric_update_timeout与local_metric_update_timeout为300s尚未启用任何评分器——这正是多机部署时需要重点改造的部分。Cubelet 节点元数据和资源配额不在CubeMaster 配置里而是由每台 Cubelet 上报。one-click 环境中的主要入口是配置位置说明Cubelet 静态配置/usr/local/services/cubetoolbox/Cubelet/config/config.toml包含node_status_update_frequency修改后重启 CubeletCubelet 动态配置/usr/local/services/cubetoolbox/Cubelet/dynamicconf/conf.yaml包含host.scheduler_label和host.quota修改后重启 Cubelet常见 Cubelet 动态配置示例host: scheduler_label: default-cluster quota: mcpu_limit: 0 mem_limit: mvm_limit: 0 creation_concurrent_num: 00或空值通常表示让 Cubelet 按宿主机资源推导默认值不等于无限资源。压测或大规模集群中如果要提高密度应显式评估 CPU、内存、MVM 数量和并发创建上限而不是依赖推导值兜底。CubeMaster 如何选择计算节点一次 sandbox 创建请求进入 CubeMaster 后调度大致分为四步解析请求约束读取instance_type、模板 ID、资源规格、显式 host IP、node affinity / annotations 等条件。预过滤节点排除不健康、资源上报过期、超过 MVM 上限、模板本地副本不可用、实时或本地观测创建数过高、不满足 affinity 的节点启用diskfilter 或 backoff 路径时也会排除磁盘使用过高的节点。节点评分对过滤后的候选节点计算分数例如基于mvm_num、local_create_num、quota_cpu_usage、quota_mem_usage做加权平均。最终选择从评分靠前的一组节点中选择。priority_select_num控制进入最终随机选择的高分节点数量least_select_name默认为random。从源码看过滤器与评分器均通过注册表按名称实例化过滤器注册表 中定义了cpu、mem、template_locality、realtime_create_num、disk、thirtparty六种过滤器评分器注册表 中定义了real_time_weighted_average、multi_factor_weighted_average、affinity_score、image_score四种评分器。NewSelector会逐个读取enable_filters/enable_scorers中声明的名称并通过反射调用构造函数因此配置中出现的名称必须与注册表严格一致。如果没有配置评分CubeMaster 仍会做过滤但可能按候选列表顺序选择节点导致新 sandbox 更容易集中到第一个可用节点直到资源过滤器把流量推向其他节点。关键 scheduler 字段推荐把下面的评分相关配置合并到现有cubemaster.yaml的scheduler段中。除非确实要替换否则请保留已有的filter、超时和实例类型专用配置。scheduler: # 保留当前部署已有的 filter、超时和其他 scheduler 配置。 priority_select_num: 3 score: enable_scorers: - real_time_weighted_average resource_weights: mvm_num: 2 local_create_num: 3 quota_cpu_usage: 1 quota_mem_usage: 1 plugin_conf: real_time_weighted_average: weight: 1.0 enable_weight_factors: - mvm_num - local_create_num - quota_cpu_usage - quota_mem_usage字段作用priority_select_num从评分最高的前 N 个节点中做最终选择。多节点建议大于1小集群可从3开始。metric_update_timeout节点资源指标多久未更新后视为不可调度。应明显大于 Cubelet 上报周期。local_metric_update_timeout预留的本地指标超时字段。当前 prefilter 对全局指标和本地指标的新鲜度检查都使用metric_update_timeout。filter.enable_filters启用调度过滤器。常见过滤器包括 CPU、内存、模板本地性和实时创建并发。score.enable_scorers启用评分器。多机部署通常启用real_time_weighted_average启用时必须同时配置score.plugin_conf.real_time_weighted_average否则 CubeMaster 可能在 scheduler 启动阶段 panic。score.resource_weights控制 MVM 数、创建并发、CPU/内存 quota 使用率等因子的权重。权重越高该因子对分数影响越大对应因子也必须列在score.plugin_conf.real_time_weighted_average.enable_weight_factors中。node_max_mvm_num/node_max_mvm_num_conf全局或按实例类型限制单节点 MVM 数。Cubelet 上报的max_mvm_num也会参与实际上限计算。disk_usage_max_percentdiskfilter 和 backoff 路径使用的磁盘水位阈值用于避免继续调度到快满的机器。affinityconf/node_affinity_selector_allowed_keys控制按 cluster label、zone、CPU 类型、机型等做亲和或约束选择。几点从配置解析与默认值逻辑中可以得到印证的事实见 config.gonode_max_mvm_num缺省为3000node_max_mvm_num_reserve_num_percent缺省为1.0disk_usage_max_percent缺省为80.0即磁盘使用超过 80% 即触发diskfilter 拦截priority_select_num缺省为-1metric_update_timeout与local_metric_update_timeout缺省为1h模板中显式写为300screate_concurrent_limit属于cubelet_conf段缺省为100是节点create_concurrent_num: 0时调度层的回落值。权重因子名称均定义在 constants.go除了本文示例用到的mvm_num、local_create_num、quota_cpu_usage、quota_mem_usage还支持req_cpu、req_mem、cpu_util、mem_usage、cpu_load、metric_update、metric_local_update_at、create_concurrent_limit、realtime_create_num、data_disk_usage、storage_disk_usage、sys_disk_usage、image_id、template_id等因子可按需启用。评分器源码级原理real_time_weighted_average评分器的实现位于 realtimescore.go。其NewRealTimeWeightedAverageScore构造函数在score.plugin_conf.real_time_weighted_average配置缺失时会直接panic——这就是文档强调启用评分器必须同步配置 plugin_conf的原因。评分计算分两步计算总权重遍历enable_weight_factors中每个因子从resource_weights取值累加得到totalWeight见getRealTimeTotalWeight若总权重为 0评分器直接返回空结果。逐节点打分getRealtimeWeightedAverageScore先调用getFactorWeightedAverageScore汇总已启用因子的加权分再额外叠加请求资源剩余量得分。各因子打分函数在 utils.go 中实现getMvmNumScore100 - MvmNum / MaxMvmLimit * 100节点承载的 MVM 数越接近上限得分越低getLocalCreateNumScore基于LocalCreateConcurrentLimit与健康 Master 节点数的乘积推算全局本地并发占用100 - f*100getQuotaCpuUsageScore/getQuotaMemMbUsageScore100 - EffectiveAllocated(Usage) / Quota * 100quota 使用率越高得分越低getRealTimeCreateNumScore100 - RealTimeCreateNum / CreateConcurrentNum * 100。此外若请求携带 CPU/内存资源量还会用getReciprocal计算剩余可分配量 / 总配额并乘以req_cpu/req_mem权重。每个因子的权重通过getFactorWeight从score.resource_weights读取未配置的因子权重为 0。最终得分除以总权重得到归一化分数随后priority_select_num从最高分的前 N 个节点中做随机最终选择。因此权重设置的本质是控制负载均衡倾向local_create_num权重高会强化创建并发均匀分布mvm_num权重高则倾向均匀铺开 MVM 数量quota_cpu_usage/quota_mem_usage权重高则更贴合节点真实资源水位。节点元数据如何影响调度Cubelet 会通过 CubeOps 的/internal/v1/node-agent接口注册节点并持续上报状态。CubeOps 将这些数据持久化到 MySQL/RedisCubeMaster 每隔几秒从 CubeOps 同步节点视图并维护本地缓存调度时读取最新快照sync_meta_data_interval、sync_metric_data_interval、collect_metric_interval在 cubemaster.yaml 中均默认1s。Cubelet 上报字段来源调度影响instance_typeCubelet 节点身份 / 实例类型用于匹配请求的instance_type、按类型选择模板副本、套用按类型的 MVM 配置。cluster_labelhost.scheduler_label用于 cluster label 亲和、隔离不同节点池或指定模板分发范围。quota_cpuhost.quota.mcpu_limit或宿主机推导值CPU 可调度容量参与 CPU 过滤和评分。quota_mem_mbhost.quota.mem_limit或宿主机推导值内存可调度容量参与内存过滤和评分。max_mvm_numhost.quota.mvm_limit或按内存推导单节点可承载的 MVM 数上限超过后节点会被过滤。create_concurrent_numhost.quota.creation_concurrent_num节点上报的创建并发配置。0表示 Cubelet 不设置额外 engine flow limit但 CubeMaster 调度层仍会回落到cubelet_conf.create_concurrent_limit缺省100。allocated / disk usage / cgroup metricsCubelet 周期上报用于判断当前资源使用率、磁盘水位和评分因子。这些值是每个计算节点独立配置和上报的。异构集群中不同节点可以有不同实例类型、标签、配额和并发上限。部署变量映射one-click 多节点变量 / 配置影响ONE_CLICK_DEPLOY_ROLEcompute安装计算节点只运行 Cubelet 等运行时服务并向控制面注册。CUBE_SANDBOX_NODE_IP当前节点注册到 CubeOps 的可路由地址。配置错误会导致节点不可达或不出现。ONE_CLICK_CONTROL_PLANE_IP/ONE_CLICK_CONTROL_PLANE_CUBEOPS_ADDRCubelet 注册和上报使用的 CubeOps 地址端口 3010。CubeMaster 单独监听 8089。Cubelet/config/config.toml中的node_status_update_frequency节点状态和资源上报周期。默认1s不要配置到 dynamicconf。Cubelet/dynamicconf/conf.yaml中的host.scheduler_label节点池标签用于 affinity 和隔离。Cubelet/dynamicconf/conf.yaml中的host.quota.*CPU、内存、MVM 数、创建并发等调度容量。Tencent Cloud Terraform / TKE变量影响TENCENTCLOUD_COMPUTE_NODE_COUNTPVM 计算节点数量直接决定可承载 sandbox 的节点池规模。TENCENTCLOUD_COMPUTE_INSTANCE_TYPE默认计算节点机型影响真实 CPU/内存和 Cubelet 推导出的 quota。TF_VAR_compute_instance_types逐台指定异构计算节点机型。适合压测或混部场景。TENCENTCLOUD_COMPUTE_DATA_DISK_SIZE每台计算节点/data/cubelet数据盘大小影响模板、快照和运行时数据容量。TENCENTCLOUD_CUBELET_NODE_STATUS_UPDATE_FREQUENCYTerraform 安装时写入每台计算节点的 Cubelet 静态配置控制节点状态/资源上报频率。TENCENTCLOUD_TKE_NODE_COUNT/TENCENTCLOUD_TKE_WORKER_INSTANCE_TYPE控制面 Pod 资源不直接承载 sandbox但会影响 CubeMaster、cube-api、cube-proxy 等控制面吞吐。TENCENTCLOUD_COMPUTE_NODE_COUNT和TENCENTCLOUD_TKE_NODE_COUNT是两套资源前者运行 Cubelet 并承载 sandbox后者运行控制面 Pod。扩容时不要只加 TKE 节点计算节点池才是 sandbox 的真正容量来源。推荐配置小测试集群适合 POC、功能验证和少量并发。下面是新建小测试集群可用的完整起始配置包含随项目提供的超时和过滤器默认值如果是在已有部署上调整请按需合并不要盲目替换无关的 scheduler 配置。scheduler: priority_select_num: 3 metric_update_timeout: 300s local_metric_update_timeout: 300s filter: enable_filters: - cpu - mem - template_locality - realtime_create_num score: enable_scorers: - real_time_weighted_average resource_weights: mvm_num: 2 local_create_num: 3 quota_cpu_usage: 1 quota_mem_usage: 1 plugin_conf: real_time_weighted_average: weight: 1.0 enable_weight_factors: - mvm_num - local_create_num - quota_cpu_usage - quota_mem_usage建议至少 2 台计算节点便于验证节点选择和故障隔离。priority_select_num从3开始如果计算节点少于 3 台可以设为节点数。Cubelet 上报周期保持默认1sCubeMaster 指标超时保持300s。host.quota使用默认推导值即可但压测前必须显式检查是否过低。较大生产类集群适合更高并发或长期运行按节点池设置清晰的host.scheduler_label例如通用池、内存型池、压测池避免不同用途互相挤占。为不同instance_type配置node_max_mvm_num_conf不要把大规格节点和小规格节点套同一组上限。从 config.go 可以看到node_max_mvm_num_conf按实例类型匹配未匹配的类型回落到全局node_max_mvm_num。适当增大priority_select_num通常可设置为健康计算节点数的一个小比例但不建议大到完全随机。保留template_locality过滤器确保创建只落到已有模板副本的节点。为host.quota.creation_concurrent_num设置明确上限避免镜像、磁盘或 VMM 创建在单节点上被突发流量打满。控制面也要扩容提高TENCENTCLOUD_TKE_NODE_COUNT和控制面 Pod 副本数避免 CubeMaster 或 cube-api 成为瓶颈。新增计算节点后的 template redo新增 compute node 后节点注册成功并不代表所有模板都已经在该节点可用。调度器的template_locality过滤器实现见 template_locality.go会要求目标节点具备可用模板副本否则创建请求可能失败或只调度到旧节点。对镜像构建模板新增节点后必须执行 template redo把模板副本分发/重建到新节点cubemastercli tpl redo \ --template-id tpl-id \ --node node-ip说明--node接受节点 ID 或 host IP多个节点可以重复传入--node。redo默认会等待任务完成如只提交任务可使用--detach。如果只想重做失败节点可使用--failed-only。redo 完成后再创建使用该模板的 sandbox避免调度因模板不可用失败。建议在多节点扩容流程中把 template redo 作为固定步骤安装计算节点并确认它出现在 CubeMaster 节点列表。确认该节点健康、Cubelet 资源上报正常。对需要在该节点运行的模板执行cubemastercli tpl redo --template-id tpl-id --node node-ip。等待 redo job 成功后再放开业务流量或运行 E2E。排障调度失败或返回 no more resource检查方向quota_cpu/quota_mem_mb是否低于实际创建需求。host.quota.mcpu_limit、host.quota.mem_limit、host.quota.mvm_limit是否仍为默认推导值。mvm_num是否达到max_mvm_num或node_max_mvm_num_conf上限。有效创建并发上限是否阻塞了当前节点。注意create_concurrent_num: 0在调度层仍会回落到 CubeMaster 的cubelet_conf.create_concurrent_limit。常用入口curl http://127.0.0.1:3010/internal/v1/nodes sudo tail -F /data/log/CubeMaster/cubemaster-req.log sudo tail -F /data/log/Cubelet/Cubelet-req.log节点状态或资源上报过期如果 CubeMaster 日志中出现 metric update timeout 类似信息确认计算节点cube-sandbox-cubelet.service正常运行。确认ONE_CLICK_CONTROL_PLANE_CUBEOPS_ADDR或 Terraform 生成的 CubeOps 地址从计算节点可达。检查node_status_update_frequency是否被误改得过大。确认metric_update_timeout明显大于上报周期。模板不可用典型现象是新节点加入后创建仍只落到旧节点或日志中提示模板本地副本不可用。处理确认请求使用的template_id。对新增节点执行cubemastercli tpl redo --template-id tpl-id --node node-ip。查看模板 job 状态确认 redo 成功。保留template_locality过滤器不建议为了绕过问题关闭它。Node label 不匹配如果请求设置了 node affinity、cluster label 或特定 instance type但没有候选节点检查 Cubelethost.scheduler_label是否与请求或affinityconf中的标签一致。检查instance_type是否与模板和请求匹配。检查node_affinity_selector_allowed_keys是否允许请求使用的 selector key。默认允许集合包括 zone、cluster id、CPU 类型、内存大小、CPU 核数、实例类型等键见 config.go。对异构节点池确认模板副本已经 redo 到对应标签/机型的节点。创建集中在少数节点如果多机集群中新 sandbox 仍明显集中在一台机器确认score.enable_scorers已启用。启用real_time_weighted_average时确认score.plugin_conf.real_time_weighted_average.enable_weight_factors包含预期因子。将priority_select_num设置为大于1。检查local_create_num、mvm_num、quota_cpu_usage、quota_mem_usage权重是否存在。确认各节点模板副本都可用否则template_locality会让候选节点集合变小。相关文档多机集群部署腾讯云集群部署Terraform服务管理与日志模板相关排障【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考