K8s集群删除节点后对应Job仍在运行是否为正常行为？如何修复

问题结论 #

这个现象属于K8s的默认正常运行机制，并非故障。

原因解释 #

你手动执行kubectl delete node操作时，仅会将对应节点的API对象从etcd中标记删除，控制面默认不会主动向节点上运行的kubelet进程下发停止现有Pod的指令：

• 只要被删除的节点本身（服务器/虚拟机）还在正常运行，且节点上的kubelet服务没有中断，kubelet就会继续管控本机运行的所有负载，包括你创建的Job对应的Pod，直到Pod的内置命令执行完毕自动退出。
• K8s默认的节点失联宽限时长为5分钟（对应kube-controller-manager的--node-monitor-grace-period默认参数），你运行的Job执行逻辑是sleep 300刚好为5分钟，在控制面触发节点Pod驱逐流程前，Job就已经执行完成，因此会出现你观察到的现象。

调整配置实现删除节点后立即终止负载的方法 #

如果需要删除节点后，节点上的运行负载立刻终止，可以按照如下需求调整配置或操作：

• 缩短节点失联判定阈值：修改kube-controller-manager的启动参数--node-monitor-grace-period，将默认的5分钟调整为你预期的时长（例如30s），控制面就会在节点心跳中断对应时长后，快速触发节点上Pod的驱逐流程。注意该参数不宜设置过短，避免网络波动引发的误驱逐。
• 执行节点删除时添加强制参数：运行删除节点命令时添加强制参数，命令为kubectl delete node <你的节点名称> --force --grace-period=0，执行后控制面会立即触发对应节点上所有Pod的驱逐逻辑，将Pod状态标记为Terminating。
• 先排空节点再执行删除：如果节点本身还需要保留运行，建议在删除节点前先执行排空操作kubectl drain <你的节点名称> --ignore-daemonsets，该操作会主动通知节点上的kubelet停止所有非DaemonSet管理的Pod，排空完成后再删除节点即可实现负载的立即终止。如果节点服务器可以直接关停，也可以在删除节点API对象的同时直接下线节点服务器，从底层停止Pod的运行环境。

内容的提问来源于stack exchange，提问作者Luke Solomon