微软在Azure Kubernetes Service（AKS）节点自动配置（Node Auto-Provisioning，NAP）中加大了对中断的控制力度，并发布了新的指南，帮助平台团队平衡自动化节点整合的效率优势与应用程序的可用性。核心思想是，如果要在缩放、升级和维护期间保持 Kubernetes 环境的可预测性，那么 NAP 自动移除、替换和整合节点的能力需要在工作负载和基础设施层面进行管理。
NAP 基于开源的Karpenter项目，可以根据待处理工作负载自动配置和管理节点，并且可以随后移除未充分利用的基础设施。虽然这可以改善装箱效率（bin-packing）和降低云成本，但自动化节点移除在 Kubernetes 环境中引入了另一种形式的变化。微软表示，用户遇到的许多运维问题与工作负载在 NAP 尝试清空和移除节点时的响应方式有关。
微软的指南强调了两种互补机制。在应用层，Kubernetes Pod中断预算（Kubernetes Pod Disruption Budgets，PDB）决定了在节点整合等操作期间可以自愿驱逐多少副本。在基础设施层，NAP 提供了控制节点本身如何以及何时被中断的能力，包括整合策略、中断预算、节点过期和漂移管理。
这种区分很重要，因为这些机制解决了不同的问题。PDB 保护应用程序的可用性，而 NAP 的中断控制规约了基础设施变化的速度和情境。微软建议将两者结合使用，而不是期望任一机制单独提供完全的保护。
指南中最有用的一个警告涉及过度限制的 Pod 中断预算。将 PDB 配置为 maxUnavailable:0，或者实际上要求 100%的副本保持可用，这可能会导致 Kubernetes 无限期地无法自愿驱逐 pod。这有可能导致 NAP 无法清空节点，意味着整合、升级和迁移可能会陷入停顿。
答案不是简单地放松每个 PDB。相反，团队需要将中断策略与每个工作负载的实际可用性要求保持一致。对于存在足够副本的服务，允许少量的愿中断（例如，一个不可用的副本）能够让基础设施维护进行，而不会对客户产生实质性地影响。
NAP 的整合能力体现了更广泛的权衡。配置为 WhenEmptyOrUnderutilized 时，NAP 可以评估工作负载是否可以移到更高效的虚拟机组合上，然后移除不必要的容量。运营商还可以使用 consolidateAfter 延迟整合，而 expireAfter 可以强制最大的节点生命周期。
这将基础设施优化转变为连续的决策过程。该平台实际上在问：我能否以不违反施加在它们周围的约束的方式更高效地运行这些工作负载？这非常强大，但这也意味着 Kubernetes 运营商需要理解影响这些决策的策略，而不是将自动伸缩视为一个不透明的机制。
微软还在自愿和非自愿中断之间做出了重要区分。NAP 的中断控制和 Kubernetes PDB 主要管理自愿操作，如整合、漂移和节点过期。它们不会阻止硬件故障、主机故障或Azure Spot VM驱逐等事件。
特别是对于 Spot 实例，中断是经济模型的一部分。AKS 可以检测即将到来的驱逐并开始配置替代容量，但使用 Spot 基础设施的应用程序仍然需要设计为能够容忍中断。
这在 AKS 之外变得越来越重要。Kubernetes 本身正在向更复杂的节点配置和整合能力发展，而 Karpenter 在云环境中提供了类似的概念。Kubernetes文档将节点自动伸缩描述为一种动态配置和整合节点以响应需求和优化成本的机制。
因此，平台工程团队面临的挑战正在从"我们如何使 Kubernetes 进行伸缩？"转变为"我们如何使自动伸缩变得安全？"。微软的 NAP 指南提供了一个有用的模型：使用应用级可用性约束保护工作负载，使用中断策略控制基础设施变化，并明确定义哪些工作负载可以容忍中断。
随着 Kubernetes 变得越来越具有自主性，特别是当集群支持越来越昂贵的 AI 和数据工作负载时，控制基础设施何时发生变化、一次可以改变多少以及遇到故障时会发生什么的能力可能会变得与配置容量的能力一样重要。
查看英文原文：AKS Looks to Make Node Disruption More Predictable with New NAP Guidance
