AKS集群autoscaler配置修改与节点池缩容降本相关技术问询

一、节点数缩减规划的核心考量要素 #

基于你当前集群已开启autoscaler、通过Pod requests值估算节点利用率的前提，规划缩容时需重点关注以下要素：

• 先核算基准承载下限：先统计所有运行业务Pod的CPU、内存requests总和，除以单台用户节点的allocatable可分配资源（注意扣除AKS节点默认预留的kubelet、系统组件资源，不要直接用节点裸规格计算），得到能承载所有现有Pod的最小节点数，这是你缩容的绝对下限，不能低于这个值。
• 预留足够的容灾和扩容冗余：至少预留10%或者1台节点的冗余空间，应对单节点故障时的Pod迁移、业务高峰期的HPA replicas扩容需求，避免出现Pod无节点可调度的情况。
• 排查特殊Pod的调度限制：检查有没有配置PodDisruptionBudget导致无法驱逐的Pod，或者挂载了本地持久化存储的Pod，还有用户侧部署的DaemonSet类 workload，这类Pod每台节点都会固定占用资源，核算利用率的时候要把这部分消耗算进去，避免漏算导致缩容后资源不足。
• 控制缩容节奏：不要一次性批量删除大量节点，建议分批缩容，每次调整后观察10~30分钟，确认所有Pod调度正常、业务无异常再进行下一批操作。
• 对齐自动扩缩容的最小节点配置：要确保节点池配置的min-count值不低于你核算出来的缩容后最小节点数，避免autoscaler自动把节点数拉到低于安全值。

二、scaleDownUtilizationThreshold参数调整说明 #

AKS 1.19.11版本完全支持修改autoscaler profile的scaleDownUtilizationThreshold参数，该参数默认值为0.5，即节点的requests资源占比低于50%就会被纳入缩容候选列表。
将该值提升至70%属于生产环境常用的成本优化方案，整体是比较推荐的，但需要结合你的业务场景判断适配性：

• 如果你的业务流量平稳，没有大规模突发扩容的需求，能接受1~2分钟的Pod调度等待时间（autoscaler扩容新节点的常规耗时），70%的阈值是非常合适的，能把整体资源利用率提升到健康区间，同时不会对业务稳定性造成明显影响。
• 如果你的业务峰值波动极大，经常出现短时间内大规模扩容Pod的情况，建议把阈值控制在60%~65%区间，预留更多的调度冗余，避免高峰期Pod长时间pending。
• 调整完成后建议观察1~2周的集群运行指标，重点关注节点扩缩容频率、Pod pending时长两项核心指标，如果出现频繁的节点扩缩容抖动、大量Pod长时间无法调度的情况，调回原有阈值即可恢复。

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