为什么node被删除后pod也会跟着删除

结论

删除 Node 对象后，该 Node 上的 Pod 会跟着被删除，不是 etcd 级联删除，而是 kube-controller-manager 里的 Node Controller watch 到 Node 删除事件后，主动遍历 spec.nodeName 指向该 Node 的所有 Pod，逐个调用 apiserver 删除。整个动作发生在控制面，不依赖节点上的 kubelet，所以即使节点已经失联、Pod 还卡在 Terminating，删 Node 也能把它们清掉。

版本说明

本文分析的是 Kubernetes Node Controller（NodeLifecycleController）对节点删除的处理机制，该机制在各稳定版中一致，以 v1.2x 为准。

详细分析

Node 和 Pod 之间不是父子关系

Pod 调度完成后，spec.nodeName 指向它所在的 Node。但要注意：

• Node 和 Pod 之间没有 ownerReference，Pod 并不是被 Node "拥有"的子对象。
• 所以删除 Node 时，垃圾回收器（GC）不会像删 Deployment 自动删 ReplicaSet/Pod 那样自动级联删 Pod。
• Pod 跟着 Node 一起消失，是控制器逻辑做的，不是 etcd 的对象依赖机制。

谁在删 Pod：Node Controller

kube-controller-manager 里的 Node Controller 一直在 watch Node 对象：

• 当 Node 被删除（或长时间 NotReady / Unknown），Node Controller 会列出所有 spec.nodeName == 该Node 的 Pod。
• 对这些 Pod 逐个发起删除（API-initiated eviction / DELETE pod）。
• 删除请求发到 apiserver 后，Pod 对象被标记删除，进而从 apiserver 移除、释放名字。

关键在于：这个删除动作是 Node Controller 在控制面主动发起的，它直接调用 apiserver，根本不需要通知节点上的 kubelet。

为什么删 Node 能解卡 Terminating

节点失联时，kubelet 不在线，Pod 上的 finalizer 无人摘除，Pod 卡在 Terminating。此时删除 Node 对象：

• Node Controller watch 到 Node 删除，主动把该节点上所有 Pod 删掉。
• 这个删除走的是控制面链路，绕过了"等 kubelet 确认容器已停止"这一步。
• 所以卡着的 Pod 会被一并清掉，名字也被释放，控制器可以在健康节点上重建 Pod。

官方文档把"删除 Node 对象"列为从 apiserver 移除卡死 Pod 的三种正规途径之一（另外两种是失联 kubelet 恢复后自行清理、用户强制删除）。

和节点正常时驱逐的区别

• 节点正常下线用 kubectl drain：先 cordon，再走 Eviction API，遵守 grace period 和 PDB，优雅迁移。
• 节点失联但 Node 对象还在：Node Controller 不会立刻删 Pod，而是等 --pod-eviction-timeout（默认 5 分钟）才开始驱逐，这是给"节点只是暂时网络抖动"留的缓冲；到点后直接在控制面删 Pod，不等 kubelet 确认容器已停止。
• 直接 kubectl delete node：Node Controller watch 到 Node 对象被删，立即清理上面所有 Pod，没有那 5 分钟等待，适合节点已不可恢复的场景。