Kubernetes检测删除多余节点耗时及自动缩容问题咨询

集群是否会自动执行缩容 #

只要你部署的是官方标准Cluster Autoscaler（CA）组件，没有手动修改配置禁用缩容逻辑，集群一定会自动回收扩容产生的空闲节点。你测试时单节点Pod数超过110就触发扩容，正好匹配EKS通用规格EC2节点默认的110个Pod调度上限，属于CA的标准触发逻辑，只要扩容逻辑正常，缩容逻辑默认也是开启的。

你目前等了10分钟节点还处于Ready状态是正常现象，并不是缩容功能失效。

自动删除多余节点的默认耗时 #

CA不会在工作负载删除后立刻回收节点，整个流程受默认参数和校验规则约束，总耗时通常在12~20分钟区间，实际耗时比你预想的长，主要是受这几个规则约束：

• 冷却计时起点不是你删除Deployment的时间，而是最后一个非DaemonSet管理的业务Pod从待回收节点上完全驱逐、节点资源预留率低于缩容阈值的时间点。默认配置下scale-down-unneeded-time参数值为10分钟，也就是节点需要连续10分钟处于“无业务负载、资源闲置”的状态，才会被CA纳入缩容候选列表。你删除Deployment后，Pod终止、从节点漂移清理本身就要花1~3分钟，实际开始算冷却期的时间比你删Deployment的时间晚几分钟很正常。
• 节点进入缩容候选列表后，CA还会做一轮合规校验，只要满足任意一条就会跳过缩容：
  • 节点上存在挂载本地存储（emptyDir、本地PV）的Pod，驱逐这类Pod可能导致数据丢失
  • 节点上运行着kube-system命名空间下的非DaemonSet管理的关键组件Pod，且这些Pod没有配置容忍可以调度到其他节点
  • 节点上的Pod被PodDisruptionBudget规则拦截，不允许驱逐
  • 节点被打上了cluster-autoscaler.kubernetes.io/scale-down-disabled: "true"标签，被手动标记为不可缩容
• 校验通过后CA才会触发节点回收流程：先给节点打污点驱逐剩余Pod，再调用Auto Scaling Group接口终止EC2实例，这个流程本身还要花1~3分钟，节点不会瞬间从集群消失。

缩容异常排查方法 #

如果等待超过20分钟节点仍未被回收，可以直接查看CA组件日志定位原因，EKS环境下CA默认部署在kube-system命名空间，执行以下命令即可捞取最近的日志：

kubectl logs -n kube-system -l app=cluster-autoscaler --tail=100

日志会明确标注每个节点未被缩容的具体原因，比如还在冷却周期、存在阻止驱逐的Pod、资源阈值未达标等。

如果觉得默认10分钟的冷却等待时间太长，可以修改CA的scale-down-unneeded-time启动参数调整时长，不建议把这个值设到5分钟以内，否则容易出现节点刚被回收、马上又因为新的调度需求扩容的资源抖动问题。

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