为什么EKS节点组未自动扩容以调度新的Pod？

你对集群自动扩容触发逻辑的基础认知没有错误：因资源不足处于Pending状态的Pod，是K8s集群自动扩缩容组件（Cluster Autoscaler，以下简称CA）触发节点扩容的核心判定条件。你遇到的扩容未生效问题，核心是踩中了EKS的常见认知误区：EKS节点组本身仅提供实例数调整的能力，不会主动感知集群内的Pod调度状态，扩容触发逻辑由独立部署的CA组件实现。

常见未触发原因 #

• 未部署CA组件：这是最常见的问题，EKS集群默认不会预装CA组件，没有CA组件上报调度失败的Pod需求，即使节点组最大实例数还有余量，也不会自动触发扩容。
• CA权限配置异常：如果已经部署CA，需要确认CA关联的IAM角色具备节点组调整权限，包括查询节点组配置、修改节点组期望实例数的权限，权限不足会导致CA识别到扩容需求后无法调用EC2接口完成节点新增操作。
• 节点匹配规则校验不通过：CA会先校验扩容出的节点是否能够调度当前Pending的Pod，以下场景都会导致校验不通过，不触发扩容：
  • 节点组配置的实例类型、可用区、子网、安全组异常，没有足够的t3.xlarge实例配额，无法正常启动新的同规格节点
  • 节点组配置了自定义污点，而Pending的Pod没有配置对应容忍度
  • Pending的Pod配置了nodeSelector、节点亲和性规则，节点组的标签无法匹配对应规则
• CA运行参数配置错误：如果已经部署CA，需要排查参数配置问题：
  • scale-down-enabled参数被误关闭，会导致CA的所有扩缩容逻辑失效
  • max-node-provision-time参数设置过短，EC2节点启动还未完成就被CA判定为扩容失败取消任务
  • 扩容冷却时间配置过长，导致上一次扩缩容操作后还在冷却周期内，不会触发新的扩容
• 资源计算逻辑偏差：t3.xlarge实例的标称规格为4vCPU、16GiB内存，但节点本身的系统进程、EKS系统组件（kube-proxy、CNI插件、CoreDNS等）会占用部分资源，实际可分配给Pod的资源约为3.5vCPU、14GiB内存，第一个Pod占用2vCPU、8GiB内存后，剩余资源确实无法满足第二个Pod的资源申请，你看到的1 Insufficient cpu, 1 Insufficient memory报错本身是正常的调度失败提示。

内容的提问来源于stack exchange，提问作者Joey Yi Zhao