kubernetes自动故障迁移依靠控制器、探针、调度器与节点健康状态联动的闭环机制，节点宕机或pod崩溃后通常30秒至2分钟内完成重建与重调度；pod层由控制器比对副本数并结合livenessprobe、readinessprobe和restartpolicy实现自愈；节点层通过node controller检测notready状态并触发优雅驱逐，scheduler将新pod调度至健康节点；跨az或多集群场景依赖podtopologyspreadconstraints、balancer组件及karmada等实现智能转移；关键配置包括pdb、statefulset策略优化、拓扑调度及etcd与api server高可用保障。

Kubernetes 实现自动故障迁移，核心不靠“手动干预”，而是靠控制器、探针、调度器与节点健康状态联动形成的闭环机制。只要配置合理，节点宕机或 Pod 崩溃后，服务通常在 30 秒到 2 分钟内完成重建与重调度，无需人工介入。

Pod 层级：靠控制器 + 探针自动重启与替换

Deployment、StatefulSet 等控制器持续比对实际运行的 Pod 数量与期望副本数。一旦发现缺失（如容器崩溃、节点失联），立即创建新 Pod。

• 存活探针（livenessProbe）：检测容器是否“活着”。失败则 kubelet 直接 kill 容器并按 restartPolicy 重启（默认 Always）
• 就绪探针（readinessProbe）：决定 Pod 是否加入 Service 的 Endpoint。探测失败时，流量自动绕过，但 Pod 不被删除
• 重启策略（restartPolicy）：仅作用于单个 Pod 内容器。OnFailure 和 Always 可确保容器级自愈；Never 则交由上层控制器统一管理生命周期

节点层级：靠节点控制器 + 驱逐机制自动迁移 Pod

当节点失联（如网络中断、主机宕机），Kubernetes 不会立刻删除其上的 Pod，而是进入“优雅驱逐”流程：

Kubernetes Skills

针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。

下载

• kube-controller-manager 中的 Node Controller 每 5 秒检查一次节点心跳（通过 node.status.conditions 中的 Ready 状态）
• 若节点连续 40 秒未上报（默认 --node-monitor-grace-period=40s），会被标记为 NotReady
• 再过 5 分钟（默认 --pod-eviction-timeout=5m），该节点上所有 Pod 将被标记为 Failed，触发控制器新建替代 Pod
• 新 Pod 由 Scheduler 自动绑定到其他 Ready 节点——前提是资源充足、亲和性/污点规则允许

跨可用区/多集群：靠拓扑感知 + Balancer 协调实现智能转移

单一集群内节点故障迁移是基础能力，但真实生产环境需应对整个可用区（AZ）失效。这时需叠加更高阶策略：

• PodTopologySpreadConstraints：在调度时强制分散 Pod 到不同 topologyKey（如 topology.kubernetes.io/zone），避免单点集中失效
• Balancer 类组件（如 kube-balance 或自研控制器）：监听 Pending Pod 超时（如 180 秒未调度），识别 AZ 故障，动态将副本从主目标 Deployment（nginx-1）迁移到备用目标（nginx-2）
• 多集群控制面（如 Karmada、Cluster API）：当本地集群整体不可用时，可将流量切至灾备集群，实现跨集群故障迁移

关键配置建议：让迁移真正“自动且可靠”

光有机制不够，以下配置直接影响故障迁移是否及时、成功：

• 为关键应用设置 PodDisruptionBudget（PDB），防止滚动更新或节点维护误删过多副本
• 给 StatefulSet 启用 podManagementPolicy: Parallel 和 revisionHistoryLimit，加速有状态服务恢复
• 使用 nodeSelector / topologySpreadConstraints 替代硬编码 nodeName，避免调度被卡死
• 确保 etcd 集群高可用（≥3 节点）、API Server 前置负载均衡（如 nginx/kube-vip），否则控制平面自身故障会导致整个迁移链路中断