微软发布AKS指南规范节点中断与扩缩容

微软针对Azure Kubernetes Service（AKS）的节点自动配置（Node Auto-Provisioning，NAP）发布了新的中断管理指南，目标是在自动扩缩容、节点升级和维护期间，让基础设施变化更加可控，同时兼顾节点整合带来的效率提升、成本下降与应用可用性。

NAP基于开源项目Karpenter，可依据待处理的工作负载自动创建和管理节点，并在节点利用率不足时移除多余基础设施。这种机制能够改善装箱效率，但节点的自动替换、回收和整合也会引发Pod驱逐问题。微软指出，部分运维故障正是由于工作负载未能正确响应节点清空过程造成的。

指南建议同时采用两层保护机制。应用层使用Kubernetes Pod中断预算（PDB），限制节点整合等自愿操作期间可被驱逐的副本数量；基础设施层则通过NAP的整合策略、中断预算、节点过期和漂移管理，控制节点在何时、以何种速度发生变化。两者职责不同，PDB保护服务可用性，NAP策略约束基础设施调整，不能期待单独依靠其中一项获得完整保护。

微软特别提醒，若将PDB设置为maxUnavailable:0，或要求全部副本始终保持可用，Kubernetes可能长期无法执行自愿驱逐，进而使NAP无法完成节点清空，整合、升级和迁移也可能停滞。更合理的做法是依据工作负载的实际容灾能力设置策略。对于副本充足的服务，允许一个副本暂时不可用，通常可以在不明显影响用户的情况下完成维护。

在节点整合方面，WhenEmptyOrUnderutilized策略可评估工作负载是否能够迁移到更高效的虚拟机组合，并删除多余容量；consolidateAfter可用于延迟整合，expireAfter则可设定节点的最长生命周期。这意味着自动伸缩不再只是根据需求增减容量，而是持续判断能否在不违反工作负载约束的前提下降低资源成本，运营团队需要理解相关策略及其影响。

这些控制主要针对整合、漂移和节点过期等自愿中断，无法阻止硬件故障、主机故障或Azure Spot VM驱逐等非自愿事件。对于Spot实例，AKS可以检测即将发生的驱逐并尝试配置替代容量，但应用仍必须具备容忍中断的能力。随着Kubernetes和Karpenter持续增强节点配置与整合能力，尤其是AI及数据工作负载占用更昂贵的基础设施，平台团队需要同时定义应用可承受的中断范围、基础设施变化的节奏，以及故障发生时的应对方式。