一句话结论
微软为AKS节点自动配置发布新指南，通过分层中断策略使节点维护操作更可控可预测。
关键要点
- 指南提出双机制协同：Pod中断预算保护应用可用性，NAP中断控制规约基础设施变化速度
- 过度限制的中断预算（如maxUnavailable:0）会导致节点无法清空，使整合升级陷入停顿
- NAP整合策略支持WhenEmptyOrUnderutilized模式，配合consolidateAfter和expireAfter参数实现精细控制
- 自愿中断（整合、漂移、过期）与非自愿中断（硬件故障、Spot驱逐）需区分管理
- 团队需将中断策略与每个工作负载实际可用性要求对齐，而非简单放松所有PDB
背景与事实
微软近期在Azure Kubernetes Service节点自动配置中加强了对中断的控制力度，并发布了配套指南。该指南的核心目标是在自动化节点整合效率与应用程序可用性之间建立平衡，帮助平台团队在缩放、升级和维护期间保持Kubernetes环境的可预测性。指南明确指出，NAP自动移除、替换和整合节点的能力必须在工作负载和基础设施两个层面进行管理，才能实现预期的可预测性效果。
节点自动配置基于开源的Karpenter项目构建，能够根据待处理工作负载自动配置和管理节点，并在完成后移除未充分利用的基础设施。这种机制虽然改善了装箱效率并降低了云成本，但自动化节点移除在Kubernetes环境中引入了新的变化源。微软表示，用户遇到的许多运维问题与工作负载在NAP尝试清空和移除节点时的响应方式直接相关，而非单纯的技术故障。
指南详细阐述了两种互补机制的应用场景。在应用层，Kubernetes Pod中断预算决定了在节点整合等操作期间可以自愿驱逐多少副本，直接保护应用程序的可用性。在基础设施层，NAP提供了控制节点本身如何以及何时被中断的能力，涵盖整合策略、中断预算、节点过期和漂移管理等多个维度。这两种机制解决了不同层次的问题：前者保护应用，后者规约基础设施变化。
指南特别警告了过度限制Pod中断预算的风险。将PDB配置为maxUnavailable:0或要求100%副本保持可用，可能导致Kubernetes无限期地无法自愿驱逐pod。这将直接导致NAP无法清空节点，使整合、升级和迁移操作陷入停顿状态。正确的做法不是简单放松每个PDB，而是将中断策略与每个工作负载的实际可用性要求保持一致，对于存在足够副本的服务，允许少量自愿中断（如一个不可用的副本）能让基础设施维护正常进行，同时不对客户产生实质影响。
NAP的整合能力配置为WhenEmptyOrUnderutilized时，系统可以评估工作负载是否能移到更高效的虚拟机组合上，然后移除不必要的容量。运营商还可以使用consolidateAfter延迟整合操作，而expireAfter可以强制设定最大的节点生命周期。这种设计将基础设施优化转变为连续的决策过程，平台实际上在持续询问：能否以不违反施加在它们周围约束的方式更高效地运行这些工作负载。这种能力虽然强大，但也意味着Kubernetes运营商需要深入理解影响这些决策的策略，而非将自动伸缩视为一个不透明的机制。
影响分析
这一指南对中文开发者和平台工程团队具有直接的实践指导价值。随着Kubernetes在云环境中变得越来越具有自主性，尤其是当集群支持越来越昂贵的AI和数据工作负载时，控制基础设施何时发生变化、一次可以改变多少以及遇到故障时会发生什么的能力，可能会变得与配置容量的能力同样重要。平台团队面临的挑战正在从"我们如何使Kubernetes进行伸缩？"转变为"我们如何使自动伸缩变得安全？"，这一转变要求团队具备更精细的中断管理能力。
具体而言，国内企业在采用AKS或类似Kubernetes托管服务时，需要重新审视现有的中断策略配置。过去可能为了追求最高可用性而设置过于严格的PDB，结果却导致基础设施维护无法进行，形成恶性循环。新指南提供的模型——使用应用级可用性约束保护工作负载，使用中断策略控制基础设施变化，并明确定义哪些工作负载可以容忍中断——为国内团队提供了一套可落地的方法论。对于使用Spot实例的团队，必须认识到中断是经济模型的一部分，AKS虽然可以检测即将到来的驱逐并开始配置替代容量，但使用Spot基础设施的应用程序仍然需要设计为能够容忍中断。
适用边界
该指南的核心结论主要适用于采用AKS节点自动配置或基于Karpenter的类似节点管理系统的Kubernetes环境。对于未启用NAP或类似自动化节点整合功能的基础集群，指南中关于整合策略和节点过期的部分不适用。此外，指南针对自愿中断场景提供建议，对于硬件故障、主机故障等非自愿中断事件，NAP的中断控制机制无法阻止，需要依靠其他高可用架构设计来应对。对于使用Spot实例的特定场景，指南明确指出了中断的不可避免性，因此基于Spot的部署方案需要额外考虑中断容忍度设计。
孤本观察
指南最核心的贡献在于清晰区分了应用层保护与基础设施层控制的边界，避免了团队将PDB当作万能解的误区。值得注意的是，微软强调的"将中断策略与工作负载实际可用性要求对齐"这一原则，实际上要求平台团队建立工作负载分类体系，而非采用一刀切的中断策略配置。
常见问题
将Pod中断预算配置为maxUnavailable:0会导致什么后果？
Kubernetes将无限期无法自愿驱逐Pod，导致NAP无法清空节点，使整合、升级和迁移操作陷入停顿状态。
NAP整合策略中的consolidateAfter和expireAfter参数分别用于实现什么控制？
consolidateAfter用于延迟整合操作，expireAfter用于强制设定节点的最大生命周期。
该指南适用于哪些Kubernetes环境？哪些场景不适用？
适用于采用AKS节点自动配置或基于Karpenter的系统；未启用NAP的基础集群不适用整合策略部分，且无法应对硬件故障等非自愿中断。
使用Spot实例的团队在设计AKS应用时需要注意什么？
必须设计应用以容忍中断，因为中断是Spot经济模型的一部分，AKS虽能检测驱逐但无法阻止Spot实例的驱逐。
NAP整合策略支持Which模式来评估工作负载迁移并移除不必要容量？
WhenEmptyOrUnderutilized模式，系统会评估工作负载是否能移到更高效的虚拟机组合上，然后移除不必要的容量。
来源：InfoQ 中文 AI