办公助手、代码助手等常驻 Agent 在等待用户输入、模型响应或外部工具返回时，实际 CPU 使用量可能较低，但仍占用声明的资源申请额度。当节点已经无法按资源申请量容纳更多 Pod，而实际利用率长期较低时，可以使用节点放大，让同一节点调度更多 Agent 工作负载。
节点放大也称资源超卖。本文介绍如何利用 TKE 原生节点的节点放大能力，从控制台选择试用节点、设置放大系数和水位线、检查运行效果，并在需要时恢复原配置。
节点放大解决什么问题
调度工作负载时，需要同时区分“申请了多少资源”和“实际用了多少资源”：
概念 | 含义 | 观察重点 |
资源申请量（requests） | Pod 声明的 CPU、内存需求，用于调度计算。 | 申请量是否已经占满节点的可调度额度。 |
装箱率 | Pod 资源申请总量与节点真实容量的比值。 | 高装箱率是否伴随低实际利用率。 |
实际利用率 | 真实资源用量与节点真实容量的比值。 | 日常和业务高峰的负载，而不只是当前瞬时值。 |
节点放大系数 | 用于提高节点可调度额度的倍数。 | CPU、内存分别设置，并结合水位线限制继续调度。 |
例如，假设一个节点原始可调度 CPU 为 16 核，将 CPU 放大系数设为 1.2 后，调度额度可按 19.2 核估算。这里的 19.2 核用于解释调度容量计算，并不代表机器增加了 3.2 核物理算力；实际调度还受水位、内存、Pod 数和其他资源限制。
节点放大不会自动修改 Pod 的 requests 和 limits，也不会增加单个沙箱的配置或计算速度。目标是利用工作负载之间的空闲和错峰，提高同一节点可承载的实例数量。相关概念请参见 原生节点提升集群装箱率。
适用场景
Agent 使用场景 | 使用建议 |
常驻办公助手，多数时间等待交互 | 先观察活跃人数与资源峰值，选择少量实例所在节点试用。 |
代码助手间歇执行命令，任务高峰错开 | 可以先试用 CPU 放大，关注代码执行耗时和并发高峰。 |
批量 RL、编译或数据处理任务同时启动 | 通常具有同步资源高峰，应先做真实负载测试，不能依据空闲时利用率直接放大。 |
内存长期接近上限或存在持续增长 | 先处理内存占用和容量问题，不依靠内存放大解决。 |
独占 CPU、绑核或对尾延迟严格敏感的任务 | 单独评估资源争抢和运行环境兼容性，优先保留独立节点容量。 |
如果节点资源申请量和实际利用率都不高，先将新任务调度到现有空闲资源；如果真实资源已经不足，应扩容节点池。节点放大不会解决镜像拉取失败、网络不通或工作区挂载失败。
开始前准备
本文适用于 Agent 集群中使用 TKE 原生节点 的工作负载。目标节点还需要支持所用的 Agent 运行环境；普通节点不能直接套用本功能，也不能通过修改节点标签变成原生节点。节点类型说明请参见 原生节点功能支持说明。
开始前完成以下准备：
通过控制台确认目标集群、原生节点池和节点 ID，避免在同名集群上修改配置。
准备组件和节点调度配置的管理权限，核对集群版本满足 原生节点专用调度器 的要求。
在 Node Map 中观察节点资源申请量与真实用量，至少覆盖代表性的业务高峰；计划使用动态放大时，查看近 7 天的峰值数据。
记录现有节点放大系数、水位线、调度范围和业务基线，保留配置截图，供回退使用。
选择少量可验证的节点与 Agent 实例，保留其他节点上的接管容量。明确任务退出、重试以及工作区保存方式。
使用 Cube 等沙箱运行环境时，除节点负载外，还需检查沙箱自身的资源占用、实例数量限制和就绪情况。放大 CPU、内存调度额度不会同时扩大 Pod IP、磁盘、挂载数量或其他运行时资源上限。
第一步：选择试用节点和业务基线
1. 登录 Agent Runtime 控制台，在 集群总览 中找到目标 Agent 集群。
2. 从集群详情核对关联的容器服务集群，进入 容器服务控制台。
3. 打开 TKE Insight > Node Map，选择目标集群，找到需要评估的原生节点并进入 详情。
4. 对照节点装箱率和利用率走势图，优先选择“资源申请已接近可调度上限，但业务峰值仍有余量”的节点。
5. 记录下表中的放大前数据，并在业务平台设置本次验证的实例数或并发上限。
检查项 | 需要保存的基线 |
节点配置 | 物理规格、原始可调度资源、节点数和已有放大配置。 |
资源需求 | 每个 Agent 的 requests、limits，以及节点上已有任务数量。 |
真实资源使用 | CPU、内存峰值，必要时补充 CPU 限流、内存压力和磁盘使用。 |
业务体验 | 任务成功率、首次响应时间、执行耗时和 P95/P99 延迟。 |
稳定性 | Pod 重启、OOM、驱逐、节点不就绪及任务重试情况。 |
不要只使用夜间空闲数据，也不要为验证放大效果同时修改所有实例的 requests、开启内存压缩并增加并发。一次先调整一个因素，便于判断变化原因。
第二步：开启原生节点专用调度器
在目标原生节点详情页，打开 原生节点专用调度器 开关。已经开启时，沿用现有组件并检查其配置，不重复安装。
该开关在集群范围生效，不是单个节点的独立开关。首次启用前应检查集群中其他原生节点和已有业务的调度配置；放大系数则先只配置到本次选定的节点。
第三步：设置放大系数和水位线
在目标节点详情页，单击 原生节点专用调度器 右侧的 编辑，设置规格放大和水位控制。
配置项 | 如何选择 |
CPU 静态放大系数 | 控制台范围为 1.0～3.0，保留一位小数。根据 CPU 峰值和任务耗时逐步调整，不直接使用上限。 |
内存静态放大系数 | 控制台范围为 1.0～2.0，保留一位小数。初次验证可保持 1.0，先观察增加实例后实际内存的变化。 |
调度时 CPU、内存水位 | 控制是否继续向节点调度 Pod。设置时为业务突发保留余量。 |
运行时 CPU、内存水位 | 用于运行期间的高负载判断；分别高于对应的调度时水位。达到水位不等于一定能够自动迁移任务。 |
停止驱逐水位 | 使用该配置时，应低于对应的运行时水位，避免驱逐与继续调度反复发生。 |
如何选择初始值
对于已确认 CPU 有余量、内存尚未充分评估的常驻 Agent，可以把 CPU 1.2、内存 1.0 作为一次小范围验证的配置示例。它不是所有业务的推荐值，实际是否扩大由任务成功率、延迟和资源峰值决定。
水位线按自身业务目标设置。例如，假设团队希望试用节点的 CPU 运行峰值控制在 50% 左右，可以将调度时 CPU 水位 40%、运行时 CPU 水位 60% 作为验证起点，观察突发期间的表现后调整。内存水位应根据工作负载实际峰值单独规划，不能直接复制 CPU 数值。
节点放大时内存不足可能导致 OOM 或任务中断；CPU 竞争则可能增加响应和执行耗时。因此不要仅凭 CPU 利用率低，就同时提高内存放大系数。
保存配置后重新打开编辑页，确认所选节点、CPU/内存系数及水位线已保存。首次试用时保留原有节点数量，验证完成后再决定是否回收其他空闲节点。
可选：动态放大
原生节点专用调度器 v1.4.0 及后续版本提供动态放大。具备相应版本和历史监控数据时，可在同一编辑页启用，并配置 CPU、内存目标利用率以及放大上限。
动态放大会参考近 7 天的峰值利用率调整系数，同时受配置上限和当前资源装箱情况约束。它不能预知未出现过的业务高峰，也不能替代任务并发控制。新业务或流量模式发生明显变化时，应重新检查历史数据是否仍有代表性。具体计算方式请参见 节点动态放大说明。
第四步：逐步增加 Agent 实例并验证
1. 保持 Agent 模板、镜像、requests 和 limits 不变，为本次试用的少量新实例选择目标节点或节点池的调度范围。
2. 先增加一小批实例，查看它们实际调度到的节点和就绪状态。配置放大不会自动把已有实例迁移到目标节点。
3. 让这些实例执行代表性任务，覆盖“等待输入—执行任务—等待模型或工具—再次执行”的过程。
4. 再验证多个 Agent 同时活跃时的峰值，检查业务成功率、延迟、节点资源和异常事件。
5. 只有本批次符合预先确定的业务目标，才继续增加实例数量；出现异常时停止增加，并按回退步骤处理。
通过容器服务控制台管理工作负载时，可在工作负载的调度配置中选择目标节点范围。修改已有工作负载模板可能触发重建，应优先用新建的少量实例验证，并保留业务原有运行时和存储配置。
混合使用普通节点和原生节点的集群，不要为了测试就把全部业务命名空间限制到原生节点。原生节点余量不足时，新 Pod 会等待调度。
判断是否真正生效
检查项 | 预期结果 |
配置 | 目标节点显示本次设置的放大系数和水位线。 |
调度 | 增加的实例确实运行在目标节点，而不是其他空闲节点。 |
容量 | 保持单实例 requests 不变时，目标节点能承载更多实例，资源申请总量与放大设置相符。 |
业务 | 在代表性并发和高峰下，成功率、响应及任务耗时满足自身目标。 |
稳定性 | 没有因资源压力新增 OOM、异常重启、反复驱逐或节点不就绪。 |
不要只看到配置数值变化，就认定完成了容量验证。比较前后的实际利用率时使用相同的物理资源口径，避免把分母增大后显示的占用比例下降误认为资源消耗下降。
需要通过 Kubernetes 复核节点配置时，可执行以下只读命令，替换为实际节点名：
kubectl config current-contextkubectl describe node REPLACE_WITH_NODE_NAMEkubectl get pods -A -o wide --field-selector spec.nodeName=REPLACE_WITH_NODE_NAME
在节点详情中查看
expansion.scheduling.crane.io/cpu 和 expansion.scheduling.crane.io/memory，并结合 requests、实际负载和业务结果判断。监控和事件的查看方法见 查看状态、日志与事件。运行时水位与任务保护
运行时水位不是无条件兜底机制。组件默认不会驱逐业务 Pod；只有符合可驱逐配置、副本与调度策略等条件的工作负载，才可能被重新调度。默认驱逐判断还需要至少 3 个满足低负载条件的原生节点；配置独立停止驱逐水位或其他策略时，应一并核对对应条件。
如果没有足够的接管节点，或任务不能中断，不应依赖驱逐来承受超额负载。优先降低业务并发或扩容物理节点。
与其他高阶能力配合
内存压缩减少部分冷内存页的实际占用，节点放大提高调度额度，两者作用不同。先分别验证，再评估组合使用；压缩收益不等于可按同等倍数放大节点。参见 为 Agent 集群开启内存压缩。
节点池扩缩容改变物理计算容量。节点放大验证通过后，才考虑迁移任务并回收空闲节点，请参见 管理节点池与运行容量。
启动性能测试评估实例就绪速度。开启放大后，需要在相同镜像、缓存状态和并发下重新测试，请参见 测试 Agent 工作负载启动性能。启动快不等于高密度下任务仍然稳定。
节点放大不会自动降低资源账单。只有在业务验证通过后实际减少不再需要的资源，才可能产生相应节省。
降低放大系数或回退
业务延迟上升、OOM、频繁重启或节点压力增大时，先恢复业务稳定性，再修改放大配置：
1. 暂停增加新实例，降低任务并发；必要时先通过节点池补足接管容量。
2. 等待短任务结束，保存长任务结果和工作区数据，将超出回退后容量的任务迁移或有序结束。
3. 确认目标节点剩余 Pod 的 CPU、内存 requests 能落在回退后的可调度范围，实际峰值也有余量。
4. 返回 Node Map > 目标节点详情 > 原生节点专用调度器 > 编辑，恢复记录的原系数、水位线和动态放大设置。完全取消超额调度时，CPU、内存系数恢复为 1.0，并检查动态放大配置不会再次提高系数。
5. 保存后复核配置、Pod 状态、业务指标和异常事件，确认任务在正常容量下继续运行。
调低系数不会自动迁移已运行的 Pod。仍有超额资源申请时直接关闭或卸载组件，后续节点组件重启等操作可能导致 Pod 被驱逐。因此先减少负载，再恢复配置，不把直接关闭集群级开关作为单节点回退手段。原有其他业务仍使用该组件时，应保留组件。回退行为请参见 原生节点专用调度器风险控制。
常见问题
现象 | 检查与处理 |
没有节点放大入口 | 核对节点是否为原生节点、集群版本、组件和账号权限。 |
保存后配置又发生变化 | 检查动态放大和是否存在作用到同一节点的其他策略，不反复覆盖。 |
放大后仍无法调度 | 检查水位、内存、Pod IP、Pod 上限、污点、节点选择、运行时和存储条件。 |
高负载时没有自动驱逐 | 检查工作负载是否允许驱逐、接管节点和策略条件；优先控制并发或扩容。 |
Agent 变慢或出现 OOM | 停止增加实例，保存现场并减少负载，按步骤回退，不能继续提高系数。 |
已将系数调回 1.0，节点仍然拥挤 | 检查已运行实例；回退配置不会自动释放这些实例占用的资源。 |
