迁移前巡检清单设计
节点池配置迁移是高风险操作,迁移前的全面巡检是保障迁移成功的第一道防线。巡检清单覆盖集群健康、Flux 状态、资源配额与备份策略四个维度,任何一项不达标都应中止迁移流程。
⚠ 前置条件:以下巡检项必须在迁移窗口开启前至少 24 小时完成,并生成书面巡检报告。未通过项需记录阻断原因与修复计划,经技术负责人签字后方可进入迁移步骤。
4.1 集群健康检查
集群健康检查确保底层 Kubernetes 集群具备承载迁移操作的稳定性。检查项包括控制平面状态、节点状态、系统组件可用性及关键指标水位。
| 检查项 | 命令 / 方法 | 预期结果 | 严重等级 |
|---|---|---|---|
| 控制平面组件状态 | kubectl get componentstatuses |
etcd-0, kube-apiserver, kube-scheduler, kube-controller-manager 均为 Healthy | 阻断 |
| 节点状态与资源水位 | kubectl get nodes -o wide + top node |
所有节点 Ready;CPU 使用率 < 70%,内存使用率 < 75%,磁盘使用率 < 80% | 阻断 |
| 系统 Pod 运行状态 | kubectl get pods -n kube-system |
所有系统 Pod 处于 Running 或 Completed 状态,无 CrashLoopBackOff | 阻断 |
| 节点内核与容器运行时版本 | uname -r + kubectl get node -o yaml |
内核版本 ≥ 5.10,containerd ≥ 1.6,与 Flux 兼容性矩阵一致 | 警告 |
| 集群事件异常扫描 | kubectl get events --all-namespaces --sort-by='.lastTimestamp' |
最近 1 小时内无 Warning/Error 级别事件 | 警告 |
💡 最佳实践:建议将集群健康检查脚本化,使用
cluster-health-check.sh 一键执行所有检查项,输出 JSON 格式报告供后续审计。
4.2 Flux 状态检查
Flux 自身的运行状态直接决定迁移能否被正确编排。检查重点包括 Flux 控制器 Pod 状态、GitRepository 与 Kustomization 对象的同步状态、以及 HelmRelease 的发布状态。
# 检查 Flux 控制器 Pod 状态
kubectl get pods -n flux-system
# 检查所有 GitRepository 对象的同步状态
kubectl get gitrepositories -A -o wide
# 检查所有 Kustomization 对象的应用状态
kubectl get kustomizations -A -o wide
# 检查所有 HelmRelease 的发布状态
kubectl get helmreleases -A -o wide
# 查看 Flux 控制器日志,确认无持续报错
kubectl logs -n flux-system deployment/source-controller --tail=50
kubectl logs -n flux-system deployment/kustomize-controller --tail=50
| 检查对象 | 关键指标 | 通过条件 | 严重等级 |
|---|---|---|---|
| Flux 控制器 Pod | source-controller, kustomize-controller, helm-controller, notification-controller | 所有控制器 Pod 均为 Running,重启次数 ≤ 1 | 阻断 |
| GitRepository 对象 | READY 状态, MESSAGE 字段 | READY=True,MESSAGE 为 "Fetched revision: xxx" | 阻断 |
| Kustomization 对象 | READY 状态, 最近一次应用时间 | READY=True,最近一次应用时间在 10 分钟内 | 阻断 |
| HelmRelease 对象 | RELEASE STATUS, MESSAGE | STATUS=deployed,MESSAGE 无 "failed" 或 "error" | 阻断 |
| Flux 版本兼容性 | flux version |
Flux CLI 与集群内控制器版本一致(v2.x) | 警告 |
📌 关键检查点:如果 GitRepository 对象处于 "Fetched revision" 但 Kustomization 对象 READY=False,说明 Flux 拉取代码成功但应用失败。此时必须排查 Kustomization 中的资源定义错误,否则迁移操作会直接失败。
4.3 节点池资源配额检查
节点池资源配额检查确保目标节点池有足够的容量承接迁移后的工作负载。检查维度包括节点池的可用资源、Pod 密度上限、以及是否存在资源配额限制。
# 查看节点池资源总量与已分配量
kubectl describe node <node-name> | grep -A 5 "Capacity"
kubectl describe node <node-name> | grep -A 5 "Allocatable"
# 查看节点池当前 Pod 数量
kubectl get pods -A --field-selector spec.nodeName=<node-name> | wc -l
# 查看命名空间资源配额
kubectl get resourcequota -n <target-namespace> -o yaml
| 检查项 | 计算方法 | 通过条件 | 严重等级 |
|---|---|---|---|
| CPU 剩余容量 | Allocatable CPU - 已请求 CPU | 剩余 CPU ≥ 迁移工作负载总请求 CPU × 1.5(安全余量) | 阻断 |
| 内存剩余容量 | Allocatable Memory - 已请求 Memory | 剩余内存 ≥ 迁移工作负载总请求内存 × 1.5 | 阻断 |
| Pod 密度上限 | 节点最大 Pod 数 - 当前 Pod 数 | 剩余 Pod 容量 ≥ 迁移工作负载 Pod 数 × 1.2 | 阻断 |
| 命名空间配额 | ResourceQuota 中 limits.cpu / limits.memory | 配额剩余量 ≥ 迁移工作负载总限制量 × 1.2 | 阻断 |
| 节点污点容忍度 | 检查目标节点 taints 与工作负载 tolerations | 所有迁移工作负载的 tolerations 覆盖目标节点 taints | 警告 |
⚠ 常见陷阱:节点池的 Allocatable 资源不等于 Capacity 资源。系统组件(kubelet、操作系统、容器运行时)会预留一部分资源。务必使用 Allocatable 而非 Capacity 进行计算,否则迁移后可能触发节点资源压力。
4.4 备份策略确认
备份是迁移失败后的最后一道防线。备份策略确认包括 Flux 对象配置备份、Kubernetes 资源备份、以及 etcd 数据备份三个层次。
# 备份 Flux 对象清单(YAML 格式)
flux export source git flux-system > flux-backup/flux-system-gitrepo.yaml
flux export kustomization flux-system > flux-backup/flux-system-kustomization.yaml
kubectl get gitrepositories -A -o yaml > flux-backup/all-gitrepositories.yaml
kubectl get kustomizations -A -o yaml > flux-backup/all-kustomizations.yaml
kubectl get helmreleases -A -o yaml > flux-backup/all-helmreleases.yaml
# 备份目标命名空间资源
kubectl get all -n <target-namespace> -o yaml > flux-backup/target-namespace-resources.yaml
# 验证备份文件完整性
tar -czf flux-backup-$(date +%Y%m%d%H%M).tar.gz flux-backup/
sha256sum flux-backup-*.tar.gz > flux-backup-checksum.txt
| 备份层级 | 备份内容 | 验证方法 | 通过条件 |
|---|---|---|---|
| Flux 对象配置 | GitRepository, Kustomization, HelmRelease, ImagePolicy, ImageRepository | 使用 flux diff 对比备份文件与集群当前状态 |
备份文件可被 Flux 重新 apply 且无 diff 差异 |
| Kubernetes 资源 | Deployment, Service, ConfigMap, Secret, PVC, Ingress 等 | 使用 kubectl apply --dry-run=server -f 验证 |
dry-run 返回 "created" 且无验证错误 |
| etcd 快照 | etcd 数据库全量快照 | 使用 etcdctl snapshot status 检查快照文件 |
快照文件大小 > 0,hash 校验通过,revision 与集群一致 |
| 备份存储位置 | 本地 + 远程对象存储(S3/MinIO) | 远程存储中文件可下载且 checksum 一致 | 远程存储与本地存储各保留一份完整备份 |
| 恢复演练记录 | 最近一次恢复测试报告 | 检查恢复测试日志与时间戳 | 最近 30 天内完成过至少一次全量恢复演练 |
💡 备份黄金法则:备份不是"做了就行",而是"能恢复才算数"。每次迁移前必须执行一次恢复演练,在隔离环境中验证备份文件可以完整重建 Flux 对象与工作负载。恢复演练耗时建议控制在 15 分钟以内。
4.5 巡检清单总览流程
以下 SVG 流程图展示了迁移前巡检的完整执行顺序与决策逻辑。巡检按集群健康 → Flux 状态 → 资源配额 → 备份策略的顺序执行,任一环节未通过则进入阻断流程。
4.6 巡检报告模板
每次巡检完成后,需填写以下标准化报告模板,作为迁移审批的附件材料。
| 巡检维度 | 检查项数量 | 通过项 | 未通过项 | 阻断原因 | 修复计划 |
|---|---|---|---|---|---|
| 集群健康检查 | 5 | — | — | — | — |
| Flux 状态检查 | 5 | — | — | — | — |
| 节点池资源配额检查 | 5 | — | — | — | — |
| 备份策略确认 | 5 | — | — | — | — |
| 汇总 | 20 | — | — | — | — |
📋 审批规则:汇总结果中若存在任何"阻断"等级的未通过项,迁移操作自动延期。仅当所有阻断项修复完成且重新巡检通过后,方可进入迁移执行阶段。警告项允许在迁移计划中附带风险缓解措施后继续。