关于GKE日志中“Cancelling deletion of pod”消息的技术咨询

嗨，我来帮你拆解一下这个GKE里的日志问题，我之前也遇到过类似的情况，给你梳理清楚：

为什么会出现这条日志？ #

这条日志的核心原因和Kubernetes的Taint Controller（污点控制器）直接相关：

• 当GKE节点被添加了某个污点（比如节点进入维护模式、资源紧张触发驱逐、或者GKE自动执行节点池升级/修复操作），Taint Controller会识别出那些没有对应容忍度（toleration）的Pod，发起驱逐（也就是标记Pod为删除状态），原因标注为TaintManagerEviction。
• 如果在驱逐流程还没完成的时候，触发驱逐的污点被移除了（比如节点维护取消、资源恢复、或者GKE的操作被中止），Taint Controller就会取消之前发起的Pod删除操作，这时候你就会看到Cancelling deletion of Pod <pod-namespace>/<pod name>这条日志。

当Pod第一次被标记删除时，会发生什么？ #

当Taint Controller发起驱逐，标记Pod为删除状态后：

1. Kubernetes会首先给Pod内的所有容器发送SIGTERM信号，这是一个优雅关闭的信号，目的是让应用程序有时间完成收尾工作（比如保存未提交的数据、关闭数据库连接、处理完当前请求等）。
2. 默认情况下，Kubernetes会等待30秒的优雅终止时间（你可以通过Pod的terminationGracePeriodSeconds字段自定义这个时长）。
3. 如果在这个等待时间内，删除操作被取消了（也就是你看到的日志情况），那么Pod会恢复正常运行状态——但这里要注意：如果你的应用程序已经收到了SIGTERM信号并自行退出了，那Pod还是会被删除，这是应用的行为，不是Kubernetes强制终止的。
4. 如果等待时间结束后Pod还没退出，Kubernetes会发送SIGKILL信号强制终止Pod。

为什么有时候Pod还是被删除/重新调度，甚至立刻回到同一个节点？ #

这种情况通常有几种可能性：

• 驱逐取消不及时：如果在删除操作被取消之前，Pod的优雅终止时间已经耗尽，Kubernetes已经发送了SIGKILL信号，那么Pod还是会被强制删除，之后由对应的控制器（比如Deployment、StatefulSet）重新创建新的Pod。
• 污点重复触发：GKE的一些自动化操作（比如节点池升级、节点自动修复）可能会有重试机制，第一次的驱逐被取消，但后续节点又被加上了相同的污点，导致Taint Controller再次发起驱逐，最终Pod还是被迁移。
• 调度器的决策：当Pod被删除后，控制器会立刻创建新的Pod实例，调度器会根据当前集群的节点状态（比如节点是否还有污点、资源是否充足）来选择调度目标。如果原节点的污点已经被移除，调度器很可能会把新Pod调度回原节点；如果原节点还有污点，就会调度到其他有对应容忍度或者没有冲突污点的节点。

备注：内容来源于stack exchange，提问作者Jty.tan