K8s是否会在HPA范围内扩容Pod以完成驱逐并满足PDB中断预算要求

Kubernetes 原生实现不会为了完成Pod驱逐主动触发扩容操作以满足PDB约束，你遇到的AKS自动升级时Pod驱逐被阻断的情况，属于平台设计的预期行为，不是AKS的功能缺陷。

你当前的配置参数：

• 目标业务仅运行1个Pod副本
• HPA配置：minReplicas=1、maxReplicas=2
• PDB配置：minAvailable=1

驱逐被阻断的完整逻辑链路：

1. 节点升级等操作触发Pod驱逐请求时，驱逐协调器会第一时间检查目标Pod所属的PDB规则
2. 检查规则时，协调器会将待驱逐的Pod计入“即将不可用”的统计范围，此时可用Pod数为0，低于PDB要求的minAvailable=1阈值
3. 协调器会直接暂停本次驱逐操作，全程不会向HPA、Deployment控制器发送任何扩容请求，也不会触发HPA的指标评估流程

Kubernetes的控制器架构遵循独立闭环设计，不存在跨控制器的事件联动逻辑：

• 驱逐协调器的核心职责仅为判断当前Pod状态是否满足安全驱逐条件，没有权限、也没有内置逻辑去干预其他控制器的副本数决策
• HPA的扩容决策完全基于预设的资源/自定义指标阈值触发，决策输入不包含“存在被PDB阻断的驱逐请求”这类场景信息，运行节奏和驱逐流程完全解耦
• 你之前预期的“驱逐前自动扩容满足PDB”的逻辑，需要跨控制器的事件联动机制支撑，不属于Kubernetes当前的原生设计范畴。

• 如果希望彻底解决驱逐被阻断的问题，将PDB的minAvailable调整为2确实可以实现目标，但会带来常驻的资源开销，无论业务负载高低都需要维持至少2个可用副本
• 如果不希望增加常驻冗余副本，需要自行实现驱逐流程与扩容流程的联动：在检测到驱逐被PDB阻断时，主动为目标Deployment扩容1个副本，待新Pod达到Ready状态后再重试原驱逐操作
• 该行为不属于AKS的平台缺陷，不需要向AKS团队上报功能故障；如果需要原生支持“驱逐前联动HPA扩容满足PDB”的能力，可以作为增强特性提交到Kubernetes社区，由社区评估通用性和落地价值。

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