GKE可抢占节点优雅关机差异排查：为何部分集群出现SHUTDOWN状态Pod？

这问题确实有点费解——同版本、同用可抢占节点的GKE集群，就因为公私网属性不同出现了Pod状态差异，我梳理几个你可能没注意到的配置或场景差异：

1. Kubelet优雅关机特性的实际生效状态 #

虽然GKE 1.20+默认开启优雅节点关机，但不排除公有集群的节点池被隐性修改了kubelet配置。你可以对比两个集群节点的kubelet参数：

• 取任意节点执行：kubectl get nodes <node-name> -o yaml
• 检查status.nodeInfo.kubeletFlags里是否有--feature-gates=GracefulNodeShutdown=false，或者spec.config.kubeletConfig下的gracefulNodeShutdown相关配置是否被覆盖。
  私有集群的节点大概率是默认启用状态，而公有集群可能因为某种自定义配置（比如节点池启动脚本、集群初始化时的额外参数）关闭了该特性，导致Pod无法被优雅清理，停留在SHUTDOWN状态。

2. 节点抢占时的控制平面通信差异 #

公有集群的控制平面通常暴露公网端点，而私有集群仅允许VPC内部访问。当可抢占节点被回收时：

• 公有集群的节点可能先失去公网连接，kubelet无法及时将Pod的终止状态同步到控制平面，导致Pod状态卡在SHUTDOWN；
• 私有集群的节点和控制平面在同一VPC内，网络稳定性更高，kubelet能顺利完成状态同步，Pod被正常清理。
  你可以查看SHUTDOWN Pod的事件日志：kubectl describe pod <pod-name> -n kube-system，看是否有“Failed to communicate with apiserver”这类网络相关的错误。

3. Pod终止宽限期的配置冲突 #

虽然两个集群用的是同版本组件，但某些系统Pod（比如metrics-server）的终止宽限期可能在公有集群被修改过。比如：

• 检查公有集群metrics-server的Pod YAML：kubectl get deployment metrics-server -n kube-system -o yaml
• 对比spec.template.spec.terminationGracePeriodSeconds的值，如果设置为0或者过短，Pod在节点关机时无法正常终止，就会卡在SHUTDOWN状态。而私有集群的该参数保持默认值，能顺利完成终止流程。

4. 节点池的附加特性差异 #

再仔细核对两个集群的节点池配置：

• 是否公有集群启用了节点自动修复或节点自动升级的额外策略？这些策略可能在节点抢占时干扰Pod的优雅终止流程；
• 节点池的启动脚本是否有差异？比如公有集群的启动脚本修改了kubelet的关机超时参数（--shutdown-grace-period或--shutdown-termination-grace-period），导致Pod无法及时被清理。

下一步排查建议 #

1. 先对比两个集群节点的kubelet配置，确认优雅关机特性是否都正常启用；
2. 查看SHUTDOWN Pod的详细事件和状态，定位是否有网络或终止流程的错误；
3. 核对节点池的所有配置项，包括启动脚本、附加特性、网络访问规则等；
4. 尝试在公有集群手动删除一个SHUTDOWN状态的Pod，看是否能正常清理，同时观察新节点上的Pod在抢占时的状态变化。

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