GKE集群节点池升级报错DeployPatch failed问题咨询

从你贴出的操作详情里，关键指标NODE_PDB_DELAY_SECONDS达到2454秒，说明升级流程在节点排空阶段被阻塞了40分钟以上，触发GKE升级超时后就会返回DeployPatch failed这个通用报错，不会直接打印底层根因。这类场景绝大多数是Pod中断预算（PDB）配置拦截了Pod驱逐导致的，按以下步骤排查即可：

排查步骤 #

• 先查集群排空相关事件：执行kubectl get events -A | grep -i drain，返回结果里会直接标注是否是PDB拦截、具体哪个命名空间的哪条PDB规则阻止了Pod驱逐，是最快定位问题的方式。
• 全量核查PDB配置：执行kubectl get pdb -A，逐个检查规则配置，重点排查两类问题：一是minAvailable设置为100%，二是minAvailable数值等于对应工作负载的总副本数，这两种配置会完全禁止Pod被驱逐，节点永远无法完成排空，直接导致升级失败。
• 检查滞留Pod状态：如果PDB配置无异常，执行kubectl get pods -A -o wide | grep <故障节点名称>，看滞留在待升级节点上的Pod：如果是kube-system下的核心组件（比如CNI插件、kube-proxy、CoreDNS）处于异常状态，或者业务Pod配置了超长的终止优雅期、挂载了不可驱逐的本地存储，也会导致排空卡住，累计PDB延迟。
• 核查故障节点状态：执行kubectl describe node <故障节点名称>，查看节点是否存在DiskPressure、NetworkUnavailable、KubeletNotReady这类异常状态，节点本身不健康时，GKE的节点升级代理无法正常替换节点组件，也会抛出这个通用错误。

解决方案 #

• 临时调整过严的PDB规则：如果是业务侧配置的PDB阻塞了升级，临时调低对应PDB的minAvailable数值，或者调高maxUnavailable，保证升级过程中允许至少1个Pod被驱逐即可，等节点升级完成后再恢复原有配置。注意：不要修改kube-system命名空间下GKE托管的PDB规则，这类规则由GKE自动维护，手动修改会被自动还原，不解决问题。
• 手动排空后重试升级：先给故障节点打上不可调度标记kubectl cordon <故障节点名称>，再手动执行排空命令kubectl drain <故障节点名称> --ignore-daemonsets --delete-emptydir-data，确认节点上所有可驱逐Pod都调度到其他节点后，重新触发节点池升级流程即可。
• 强制重建故障节点：如果手动排空一直卡住，直接执行kubectl delete node <故障节点名称>，GKE的节点自动修复机制会自动创建版本匹配的新节点替换故障节点，自动完成剩余升级流程。
• 优化升级策略避免后续复发：后续升级节点池时，调整浪涌升级参数，合理设置max-surge-upgrade和max-unavailable-upgrade的数值，避免单节点阻塞拖垮整个升级流程。

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