节点替换、退役与迁移
本页用于处理计算节点的计划内替换、故障替换、缩容退役和迁移。
它更偏运维实操清单，不展开控制节点数据库迁移；控制面相关内容请优先看：
适用场景
最常见的四类场景：
- 老旧硬件需要更换
- 节点长时间
degraded / not ready且短时间无法恢复 - 集群需要缩容，准备下线一个节点
- 节点 IP 或机架变化，本质上需要“先加新节点再退旧节点”
变更前先确认什么
建议至少确认：
- 已备份配置与关键目录
- 目标节点容量足够
- 旧节点上的运行中沙箱和本地模板已评估
- 已有回滚点和维护窗口
重点观察页：
最小安全顺序
如果当前版本没有明确的 drain / cordon 能力，建议采用“先扩后缩”：
- 先备份
- 先加新节点并完成健康检查
- 在 Dashboard 确认新节点
ready - 确认新节点已经具备必要模板副本
- 让旧节点业务自然排空，或在维护窗口内迁移/重建关键实例
- 旧节点无关键运行实例后再执行下线
- 最后做整体验收
场景一：计划内替换节点
推荐顺序：
- 先新增替代节点
- 先验证节点注册、模板副本和基础创建能力
- 再下线旧节点
场景二：故障替换节点
如果旧节点已明显不可恢复：
- 先保留现场日志与配置
- 先补入新节点
- 再恢复容量与副本覆盖
- 最后再处理旧节点退役
场景三：集群缩容 / 节点退役
不建议直接对仍承载关键业务的旧节点执行激进下线。
建议先确认：
Running Sandboxes是否已清空或可重建- 关键模板副本是否已覆盖其他节点
- 现有容量是否仍够支撑业务
场景四：迁移后怎么验收
建议至少验证：
- 新节点已出现在控制面节点列表
- Dashboard 节点页状态正常
- 关键模板副本已覆盖
- 至少一个最小沙箱可成功创建并产生日志