应组合api server心跳超时、kubelet条件时间戳及自定义健康探针三类指标判断节点失联；驱逐pod需通过delete+graceperiodseconds而非eviction api，并跳过job/cronjob等自动重建pod；使用informer监听节点状态变更并异步处理，结合pod annotation和configmap实现幂等迁移。
如何用 Go 判断一个 K8s 节点是否真的不可用
不能只看 Node.Status.Phase == "Unknown" 或 Node.Status.Conditions 里有没有 Ready=False —— 这些状态可能滞后几十秒甚至几分钟，而你的迁移逻辑需要更及时、更确定的信号。
真实生产中，应组合三类指标：API Server 的节点心跳超时（Node.Status.LastHeartbeatTime）、kubelet 上报的条件时间戳（Node.Status.Conditions[Ready].LastTransitionTime）、以及你自己的健康探针结果（比如通过 http.Get("https://<node-ip>:10250/healthz")</node-ip>）。
- 如果
LastHeartbeatTime距今超过 40 秒，且Ready条件的LastTransitionTime没有更新，基本可判定失联 - 直接调
/healthz要加context.WithTimeout(ctx, 5 * time.Second)，否则单个节点卡住会拖慢整个轮询周期 - 别信
Node.Status.DaemonEndpoints.KubeletEndpoint.Port，它可能是旧值；实际访问要用Node.Status.Addresses中类型为InternalIP的地址
怎样安全地驱逐节点上的 Pod 而不中断服务
直接调 client.CoreV1().Nodes().Evict(ctx, &policyv1beta1.Eviction{...}) 是错的 —— 这个 API 不适用于节点级驱逐，它是给 Pod 驱逐用的。节点故障迁移必须走 Pod 对象的 DeletionTimestamp 注入 + GracePeriodSeconds 控制。
- 对每个待迁移 Pod，先 patch 它的
metadata.finalizers，移除kubernetes.io/pvc-protection等可能阻塞删除的 finalizer（仅当确认 PVC 已 detach 或由外部存储系统管理时） - 执行
client.CoreV1().Pods(pod.Namespace).Delete(ctx, pod.Name, metav1.DeleteOptions{GracePeriodSeconds: &grace})，其中grace建议设为30（不是 0）：避免 SIGKILL 强杀引发应用状态不一致 - 注意
Pod.Spec.RestartPolicy != "Never"的 Job/CronJob Pod，删了会立即重建到其他节点 —— 这不是 bug，是预期行为，但你要在逻辑里识别并跳过它们，否则可能重复迁移
为什么用 Informer 同步节点状态比轮询 API 更可靠
轮询 client.CoreV1().Nodes().List() 看起来简单，但在高并发或网络抖动时极易漏状态变更，且无法感知 Node 对象的 ResourceVersion 跳变，导致你基于旧快照做决策。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
cache.NewSharedIndexInformer监听corev1.Node，并在EventHandler.OnUpdate中比较oldObj.(*corev1.Node).Status.Conditions和newObj.(*corev1.Node).Status.Conditions - 不要在
OnUpdate里直接触发迁移逻辑 —— 加一层带缓冲的 channel（如chan *corev1.Node），让 worker goroutine 异步处理，防止 Informer 回调阻塞 - Informer 的
ResyncPeriod设为30 * time.Second即可，太短增加 apiserver 压力，太长会导致状态漂移
如何避免迁移过程中把同一个 Pod 多次驱逐
这是最常踩的坑：节点反复进出 Unknown 状态，或者多个实例同时运行这个迁移程序，导致同一 Pod 被删了又删，etcd 里留下一堆 Terminating 卡住的残骸。
- 给每个迁移任务加唯一标识，写入 Pod annotation，例如
cluster.example.com/migrated-by: "node-failover-20240712-abc123"，下次看到这个 annotation 就跳过 - 驱逐前检查
Pod.Status.Phase == "Running"且Pod.Spec.NodeName == targetNodeName，缺一不可 —— 否则可能误删正在被调度或已迁走的 Pod - 不要依赖本地内存缓存“已处理节点列表”，要用 Kubernetes 原生机制：创建一个
ConfigMap存已处理节点名和时间戳，每次操作前先Get再Update，靠 etcd 的 CAS 保证幂等
真正的难点不在代码怎么写，而在你怎么定义“该迁”和“能迁”——比如 DaemonSet Pod 是否允许驱逐、StatefulSet 的 volume 是否支持跨节点挂载、还有那些没设 terminationGracePeriodSeconds 的遗留应用。这些没法靠一套通用逻辑兜住，得结合你集群里的 workload 类型逐个对齐。
