AWS如何实现Pod跨节点自动迁移与空闲节点缩容降本

AWS平台完全支持你描述的自动缩容降本能力，无需手动迁移Pod或操作节点下线，通过标准Kubernetes组件配合AWS集群伸缩能力即可落地，适配你当前的2节点非托管节点组场景。

你当前场景（Node1剩余CPU足够承载Node2所有Pod）的全流程自动缩容，分为三个核心环节落地，所有组件均兼容非托管节点组：

• Pod自动重调度配置
  部署社区标准的descheduler组件，启用LowNodeUtilization策略：设置合理的节点低利用率阈值（比如CPU、内存使用率低于20%即判定为空闲节点），组件会持续扫描集群节点状态，当检测到空闲节点上的所有Pod都可以被其余节点（即你的Node1）剩余容量承载时，会按照你配置的中断规则逐批驱逐空闲节点上的Pod，触发调度器将这部分Pod重新调度到资源充足的节点上。
  配置前需要给业务设置合理的PodDisruptionBudget，避免重调度过程影响业务可用性。
• 空闲节点自动缩容
  部署Cluster Autoscaler(CA)组件，关联你非托管节点组对应的EC2自动伸缩组：当CA检测到节点上所有可迁移Pod都被驱逐完成、节点持续处于空闲状态达到你设定的时间窗口（默认10分钟，可按需调整），会自动调用伸缩组接口终止该空闲节点，直接减少不必要的EC2运行成本。
• 调度策略优化，避免资源碎片化
  修改kube-scheduler的调度打分规则，启用MostRequestedPriority策略：调度器分配Pod时会优先将Pod调度到已分配资源占比更高的节点，尽可能把工作负载填充到更少的节点上，从调度逻辑上减少零散的资源碎片，避免出现「两个节点都跑了部分Pod、但单节点明明能装下所有负载」的资源浪费情况，配合前面两个组件就能完全实现你要的效果。

几个容易导致缩容失败的配置点需要提前处理：

1. 检查所有业务Pod，不要配置强制绑定Node2的节点亲和性规则，也不要给Pod添加禁止驱逐的注解，否则descheduler无法迁移这部分Pod，会导致节点无法被清空缩容
2. 给承载所有负载的节点提前配置足够的系统资源预留，通过kubelet的--system-reserved参数给系统组件、kube-proxy、容器运行时预留足够CPU、内存，避免所有Pod堆到单节点后挤压基础组件资源导致节点故障
3. 非托管节点组需要手动给Cluster Autoscaler配置对应EC2自动伸缩组的读写权限，确保组件可以正常查询节点状态、终止空闲实例

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