海外节点故障时，自动迁移不等于容器立刻在另一台机器上启动：控制面需要先判断节点失联，调度器还要找到满足资源、网络和存储条件的目标节点。要让海外应用容器集群自动故障迁移可预期，应优先核对下面四项配置，并用故障演练验证恢复过程。
一、故障检测与隔离：确认“多久判定节点失联”
在 Kubernetes 中，控制面会依据节点心跳和状态更新判断节点是否可用。节点变为 NotReady 或 Unreachable 后，相关 Pod 通常还会受到容忍时间影响；Pod 的 toleration 设置可能延后驱逐。因此，监控告警、节点状态判定和 Pod 驱逐不是同一时刻发生。
逐项检查节点心跳相关控制面参数、节点网络中断告警，以及 Pod 对 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 污点的容忍设置。不要为了追求快速迁移而随意缩短容忍时间：跨境链路抖动或控制面短暂不可达时，过早驱逐可能导致旧节点上的进程仍在运行，新节点却已启动副本，形成重复处理风险。按业务可接受的恢复时间和网络稳定性设定阈值，并记录从失联到新 Pod Ready 的耗时。
二、副本与调度约束：确保有地方接得住
只配置自动重建还不够；如果服务只有一个副本，故障期间仍可能中断。为无状态服务设置多个副本，并用节点标签、反亲和规则或 topology spread constraints 分散到不同故障域。海外集群的故障域可能是不同可用区或机房，具体标签应以集群实际定义为准。
检查节点选择器、污点容忍、亲和规则和资源请求是否过严。如果所有副本都要求落在故障节点所在区域，调度器即使正常也无法安置它们。PodDisruptionBudget主要约束自愿中断（如维护驱逐），不能代替节点故障时的副本规划；两者应分开验证。
三、持久化数据：确认卷能否在目标节点重新挂载
有状态工作负载要单独评估存储。检查 PersistentVolume 的访问模式、底层存储的可用范围，以及卷能否从故障节点卸载后挂到新节点。绑定本地磁盘的卷通常无法像网络块存储那样直接跨节点重新挂载；即使卷支持跨节点使用，也可能受可用区、驱动和云平台限制。
按以下步骤验证：
- 列出工作负载使用的 PVC、PV、存储类和卷拓扑约束。
- 确认故障节点与候选节点是否位于卷可访问范围内，并检查存储驱动状态。
- 在测试环境模拟节点失联，观察旧卷释放、新 Pod 调度和挂载过程；核对应用是否需要恢复或重放数据。
对于数据库等有状态服务，还要确认复制、选主和写入保护机制；容器重新启动不代表数据已经恢复一致。
四、容量与优先级：避免迁移后仍处于 Pending
预留足够的可调度资源，不能只看节点空闲 CPU 或内存，还应核对 Pod 的 requests、节点可分配量、配额、镜像拉取能力和网络策略。若海外区域的剩余节点无法容纳故障节点上的工作负载，自动迁移会停在 Pending。可通过预留冗余、合理设置资源请求及为关键服务配置优先级，明确资源紧张时的调度顺序；优先级不能创造额外容量，也可能挤占低优先级任务。
演练时记录节点失联、Pod 驱逐、重新调度、卷挂载和 readiness probe 通过的时间点，并检查事件与告警。以同一套指标复测不同故障域，才能判断海外应用容器集群自动故障迁移是否达到业务恢复目标，而不只是确认 Pod 最终重新运行。
常见问题
节点断网后，Pod 会马上迁移吗？
通常不会。控制面需要判定节点状态，Pod 的容忍时间和调度条件也会影响迁移开始时间。
增加副本数就能避免服务中断吗？
不能保证。副本需分散到不同故障域，并且目标节点要有足够资源；应用本身也必须能处理并发请求和实例切换。
有状态服务适合自动迁移吗？
可以设计自动恢复，但要先验证卷重新挂载、数据一致性和选主行为。仅凭 Pod 重建成功，不能判断服务已安全恢复。
最终应同时验证故障检测、调度、存储和容量，而不是只看重启结果。把恢复时间、数据风险与跨区资源成本纳入演练，才能让海外应用容器集群自动故障迁移符合实际业务要求。
