模板构建排障
本页用于处理“模板一直 BUILDING”或“模板进入 FAILED”这两类高频问题。
如果你还没做问题分层,先看:
先判断是“模板问题”还是“全局服务问题”
建议先做两步:
- 检查控制面健康状态(避免把全局异常误判成模板单点问题)
- 再进入模板详情看构建日志与最近任务
可先执行:
bash
curl -fsS http://127.0.0.1:3000/health
curl -fsS http://127.0.0.1:12088/cubeapi/v1/health如果健康检查都失败,请先回到:
高频症状与处理路径
症状一:模板长期 BUILDING
常见原因:
- 构建任务未真正推进
- 构建依赖(镜像拉取、网络、节点资源)不足
- 任务状态更新异常
建议排查:
- 先在 Dashboard 模板详情确认“最近一次构建任务 ID”
- 查看构建日志是否持续更新
- 观察是否只有个别节点缺副本
对应文档:
症状二:模板进入 FAILED
常见原因:
- 基础镜像地址不可拉取或镜像本身有问题
- 模板参数不合理(端口、探针、资源规格)
- 节点资源不足导致构建失败
建议排查:
- 回看镜像地址、探针端口和探针路径
- 回看 CPU/内存与可写层参数是否过小或过大
- 对照失败日志定位是镜像、探针还是资源问题
对应文档:
症状三:模板 READY,但部分节点无副本
常见原因:
- 节点尚未正常注册或健康度异常
- 节点资源紧张导致副本分发不完整
建议排查:
- 在节点页确认节点状态与资源余量
- 在可观测性页确认是否存在持续告警
- 结合服务日志确认是否有分发相关错误
对应文档:
最小命令检查清单
bash
# 控制面健康
curl -fsS http://127.0.0.1:3000/health
# Web 反代健康
curl -fsS http://127.0.0.1:12088/cubeapi/v1/health
# 关键服务状态(按你实际安装的服务名查看)
systemctl status cubemaster
systemctl status cubeapi
systemctl status cubelet如果服务状态异常,优先查看:
bash
journalctl -u cubemaster -n 200 --no-pager
journalctl -u cubeapi -n 200 --no-pager什么时候“重建模板”比“继续等”更合适
更适合发起重建的场景:
- 构建日志长期无新增
- 参数已明显修正(镜像、探针、资源规格)
- 已确认基础服务健康,但模板任务仍停滞
重建前建议先保存:
- 当前模板参数
- 最近失败日志关键片段
- 最近一次构建任务 ID