GKE集群缩容失败：执行调整操作后节点数仍为2个

我帮你分析下你遇到的这个问题——明明执行了resize命令且提示成功，但集群节点数还是保持2个，这通常是因为待删除的节点上有无法被正常驱逐的Pod，导致GKE没法回收这个节点。下面是具体的排查和解决步骤：

一、先排查节点上的Pod为什么无法被驱逐 #

首先，选中你想删除的那个节点（比如gke-...-default-pool-d842095f-nq6t），查看它上面运行的Pod详情：

kubectl describe node gke-...-default-pool-d842095f-nq6t

重点看以下几种可能阻止驱逐的情况：

• 带本地存储的Pod：如果Pod使用了emptyDir或者本地PersistentVolume（PV），GKE默认不会强制删除这类Pod（避免数据丢失），所以节点无法被回收。
• PodDisruptionBudget（PDB）限制：如果你的应用设置了PDB，且当前可用Pod数已经接近PDB的最小值，缩容会导致Pod数低于阈值，GKE会暂停节点删除操作。
• 调度约束：比如Pod设置了nodeAffinity绑定到当前节点，或者podAntiAffinity要求必须分布在不同节点，这会让Pod无法被调度到其他节点，进而阻止节点删除。
• 异常状态的Pod：处于ImagePullBackOff、CrashLoopBackOff的Pod可能无法正常终止，也会导致节点无法释放。

二、手动驱逐节点上的Pod #

如果确认是Pod无法自动驱逐，你可以手动标记节点为不可调度，然后强制清理Pod：

# 第一步：标记节点为不可调度，避免新Pod被调度过来
kubectl cordon gke-...-default-pool-d842095f-nq6t

# 第二步：驱逐节点上的所有Pod
# --ignore-daemonsets：忽略DaemonSet的Pod（这类Pod会自动在剩余节点重建）
# --delete-local-data：强制删除带本地存储的Pod（注意：会丢失本地数据，谨慎使用）
kubectl drain gke-...-default-pool-d842095f-nq6t --ignore-daemonsets --delete-local-data

执行完这两步后，等待几分钟，GKE会自动删除这个处于SchedulingDisabled状态的节点，此时集群节点数就会变成1。

三、检查节点池的自动扩缩容设置 #

如果你的节点池开启了自动扩缩容（Autoscaling），可能存在手动缩容后被自动扩缩容拉回节点数的情况：

1. 先查看节点池的自动扩缩容配置：

gcloud container node-pools describe mypoolname --cluster myclustername

2. 找到autoscaling字段，如果minNodeCount设置为2，那你手动改成1后，自动扩缩容会把节点数恢复到最小值2。这时候需要先调整自动扩缩容的最小值：

# 调整自动扩缩容的最小节点数为1，最大值保持原来的数值即可
gcloud container node-pools update mypoolname --cluster myclustername --enable-autoscaling --min-nodes 1 --max-nodes <你的原最大值>

3. 再重新执行resize命令：

gcloud container clusters resize myclustername --node-pool mypoolname --num-nodes 1

四、查看GKE操作日志定位具体错误 #

如果上面的方法都没用，你可以去GCP控制台的Cloud Logging，搜索以下关键词找具体报错：

• container.googleapis.com/cluster-autoscaler
• container.googleapis.com/node-pool-resize
  日志里会明确说明为什么节点无法被删除，比如“Cannot delete node because pods with local storage exist”，根据报错信息针对性解决即可。

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