Azure Kubernetes 服务修补程序和升级指南

Azure Kubernetes 服务 (AKS) 两日操作指南的这一部分介绍了针对 AKS 工作器节点和 Kubernetes 版本的修补和升级做法。 群集操作员需要制定一个计划，使群集保持最新状态，并监视一段时间内 Kubernetes API 的更改和弃用情况。

更新的背景和类型

AKS 有三种类型的更新，每个更新都基于上一个更新：

更新类型

• 节点 OS 安全修补程序（仅限 Linux）： 对于 Linux 节点，Canonical Ubuntu 和 Azure Linux 提供操作系统安全修补程序每天一次。 Microsoft 在节点映像的每周更新中测试和捆绑这些修补程序。

• 节点映像的每周更新： AKS 提供节点映像的每周更新。 这些更新包括最新的 OS 和 AKS 安全修补程序、缺陷修复以及增强功能。 节点更新不会更改 Kubernetes 版本。 对于 Linux，版本格式为日期（例如，202311.07.0）；对于 Windows，版本格式为 Windows Server OS 版本和日期（例如，20348.2113.231115）。 有关详细信息，请参阅 AKS 发布状态。

• 季度 Kubernetes 发行版： AKS 为 Kubernetes 发行版提供季度更新。 这些更新使 AKS 用户能够使用最新的 Kubernetes 功能和增强功能，例如安全修补程序和节点映像更新。 有关详细信息，请参阅 AKS 支持的 Kubernetes 版本。

升级前的注意事项

在升级 AKS 工作节点和 Kubernetes 版本之前，请考虑以下效果和最佳做法。

总体群集影响

• 节点和群集的就地升级在进行时会影响 Kubernetes 环境的性能。 通过正确配置 Pod 中断预算、节点激增配置以及适当的规划，可将这种影响降低到最小。

• 蓝绿更新策略不会影响群集性能，但它们会增加成本和复杂性。

• 无论采用何种升级和修补策略，都需要为群集提供可靠的测试和验证过程。 首先对较低的环境进行修补和升级，然后执行维护后验证，检查群集、节点、部署和应用程序运行状况。

AKS 工作负载最佳做法

若要确保 AKS 群集在维护期间顺利运行，请遵循以下最佳做法：

• 定义 Pod 中断预算 (PDB)。 为部署设置 PBD 至关重要。 PDB 强制实施最低数量的可用应用程序副本，以确保中断事件期间功能持续运行。 PDB 有助于在维护或节点故障期间维护群集的稳定性。

  警告

  Kubernetes API 会阻止在滚动节点映像升级中发生的必要隔离和排空，因此配置错误的 PDB 可能会阻止升级过程。 此外，如果同时移动过多 Pod，可能会导致应用程序中断。 适当的 PDB 配置可降低此风险。

• 检查可用计算和网络限制。 通过 Azure 门户中的配额页或使用 az quota 命令验证 Azure 订阅中的可用计算和网络限制。 请务必检查节点的计算和网络资源，尤其是虚拟机 (VM) vCPU，以及 VM 和虚拟机规模集的数量。 如果接近限制，请在升级之前请求增加配额。

• 检查节点子网中的可用 IP 地址空间。 更新期间，会在群集中创建更多的激增节点，并将 Pod 移动到这些节点。 请务必监视节点子网中的 IP 地址空间，以确保有足够的地址空间进行这些更改。 不同的 Kubernetes 网络配置 有不同的 IP 地址要求。 若要开始，请查看以下注意事项：

  • 升级期间，节点 IP 地址数会随激增值增加而增加。 最小浪涌值为 1。
  • 基于 Azure 容器网络接口的群集将 IP 地址分配给各个 Pod，因此需要有足够的地址空间进行 Pod 移动。
  • 升级期间，群集将继续运行。 确保保留足够的 IP 地址空间以允许节点缩放。

• 设置多个环境。 设置多个 Kubernetes 环境，例如开发、过渡环境和生产环境。 通过这种分离，可以在将更改移动到生产环境之前对其进行完全测试和验证。 在多个版本的 AKS 之间移动（例如 1.28 到 1.31）时，验证尤其重要。

• 计划和安排维护时段。 升级过程可能会影响 Kubernetes 群集的整体性能。 请在高峰使用时段之外计划就地升级过程，并监视群集性能，以确保适当调整大小（尤其是在更新过程中）。

• 针对不可迁移节点行为优化群集。 默认情况下，如果节点无法成功清空，则群集上的修补也会失败。 若要解决此问题，应 配置节点排空线。 此过程隔离不可排空的节点，并允许群集成功升级。 然后，可以通过修补或删除节点来手动修正未能更新的节点。

• 调整激增升级值。 AKS 的激增值默认为 1，意味着在升级过程中一次只创建一个额外的节点。 可通过增加此值来提高 AKS 升级的速度。 对于对中断敏感的工作负载，建议的最大激增值为 33%。 更多信息，请参阅自定义节点激增升级。

• 优化节点排空超时。节点排空超时指定在节点更新期间，集群在工作负载尝试重新调度 Pod 到该节点时所等待的最长时间。 默认值为 30 分钟。 对于难以重新调度 Pod 的工作负荷，增加此值可能会有所帮助。

• 优化节点浸泡超时。默认情况下， 节点浸泡配置 在节点完成更新过程后继续重新映像下一个节点。 对于某些旧工作负载或敏感工作负荷，在转到下一个节点之前，添加延迟可能很有帮助。 通过配置节点浸泡超时来添加延迟。

• 检查群集中的其他依赖项。 Kubernetes 操作人员通常将其他工具部署到 Kubernetes 集群，作为操作的一部分，例如 KEDA 扩缩工具、DAPR 和服务网格。 规划升级过程时，请查看发行说明，以确认您使用的任何组件与目标版本的兼容性。

• 优化 AKS 区域配置。 对于区域 AKS 群集，激增升级可能会暂时导致区域之间的工作负荷分布不平衡。 若要防止这种情况，请将激增值设置为 3 的倍数，例如 33%。

管理每周的节点图像更新

Microsoft大约每周为 AKS 节点创建一次新节点映像。 节点映像包含最新的 OS 安全修补程序、OS 内核更新、Kubernetes 安全更新、像 kubelet 这样的二进制文件的更新版本，以及发行说明中列出的组件版本更新。

更新节点映像时，会在目标节点池的节点上触发隔离和排空操作：

1. 已更新映像的节点将被添加到节点池。 峰值用于控制同时添加的节点数量。
2. 根据浪涌值，一批现有节点会被封锁和排除。 隔离可确保该节点不会调度 Pod。 清空会移除其 Pod 并将其调度到其他节点。
3. 这些节点完全耗尽后，就会从节点池中移除。 然后由激增添加的更新节点将它们替换。
4. 对于节点池中需要更新的每一批剩余节点，都会重复这一过程。

群集升级期间，也会发生类似的过程。

自动节点映像升级

通常，大多数群集应使用 NodeImage 更新通道。 该通道每周提供更新的节点映像虚拟硬盘 (VHD)，并根据群集的维护时段进行更新。

可用的通道包括：

• None。 不会自动应用任何更新。

• Unmanaged。 OS 每晚应用 Ubuntu 和 Azure Linux 更新。 须单独管理重新启动。 AKS 无法测试或控制这些更新的节奏。

• SecurityPatch。 OS 部署经过 AKS 测试、完全托管的安全修补程序，并使用安全部署做法。 此修补程序不包含任何 OS bug 修复。 它仅包含安全更新。

• NodeImage。 AKS 每周用新修补的 VHD 更新节点，该 VHD 包含安全性修补程序和 Bug 修补程序。 这些更新是使用安全部署做法进行全面测试和部署的。 有关当前部署的节点映像的实时信息，请参阅 AKS 节点映像更新。

若要了解未设立维护时段下的默认节奏，请参阅 更新所有权和计划。

如果选择 Unmanaged 更新通道，则需要使用 kured 等工具管理重新启动过程。 该 Unmanaged 通道不提供 AKS 提供的安全部署做法，在维护时段下不起作用。

如果选择 SecurityPatch 更新通道，则可以像每周一样频繁地应用更新。 此修补程序级别要求 VHD 存储在资源组中，因此会产生少许费用。 若要控制 SecurityPatch 何时应用，请设置 aksManagedNodeOSUpgradeSchedule 最适合工作负荷的节奏。 如果还需要新节点映像 (VHD) 通常附带的错误修复，则需要选择 NodeImage 通道而不是 SecurityPatch通道。

有关详细信息，请参阅 使用计划内维护来计划和控制 AKS 群集的升级。

最佳做法是，使用 NodeImage 更新通道，并将 aksManagedNodeOSUpgradeSchedule 维护时段配置为群集高峰使用时段之外的时间。 有关可用于配置群集维护时段的属性，请参阅 “创建维护时段”。 关键属性包括：

• name。 使用 aksManagedNodeOSUpgradeSchedule 进行节点 OS 更新。

• utcOffset。 配置时区。

• startTime。 设置维护时段的开始时间。

• dayofWeek。 将维护时段设置为一周中的某一天。 例如，Saturday。

• schedule。 设置维护时段的发生频率。 对于 NodeImage 更新，我们建议设置为 weekly。

• durationHours。 将此属性设置为至少 4 小时。

以下示例将每周维护时段设置为星期六东部时间晚上 8：00：

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

此配置理想情况下作为基础设施即代码的一部分来部署到群集。

有关更多示例，请参阅 “添加维护时段配置”。

可使用 Azure CLI 检查已配置的维护时段：

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

此外，还可使用 CLI 检查特定维护时段的详细信息：

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

如未配置群集维护时段，则每两周会更新一次节点映像。 AKS 维护尽可能在预定的时间窗口内进行，但无法保证具体的维护时间。

若要自动监视更新状态，可以使用 AKS 通信管理器 为计划内维护活动提供自动警报。 或者，可以直接通过 Azure Monitor 活动日志 或通过查看群集上的 资源日志 来 kubectl get events监视。

使用 Azure 事件网格订阅 AKS 事件以获取 AKS 升级事件。 这些事件可以在新版本的 Kubernetes 可用时发出警报，并帮助在升级过程中跟踪节点状态更改。

还可使用 GitHub Actions 来管理每周更新过程。 此方法能够更精细地控制更新过程。

手动节点更新过程

可使用 kubectl describe nodes 命令来确定群集中节点的 OS 内核版本和 OS 映像版本：

kubectl describe nodes <NodeName>

示例输出（已截断）：

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.173.1-1.cm2
  OS Image:                   CBL-Mariner/Linux
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.6.26
  Kubelet Version:            v1.31.3
  Kube-Proxy Version:         v1.31.3

使用 Azure CLI az aks nodepool list 命令来确定当前群集中节点的映像版本：

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

示例输出：

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

使用 az aks nodepool get-upgrades 命令来查找特定节点池的最新可用节点镜像版本：

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

示例输出：

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V2gen2-202501.12.0
user    AKSAzureLinux-V2gen2arm64-202501.12.0

群集升级

Kubernetes 社区大约会每隔三个月发布 Kubernetes 的次要版本。 为了便于用户随时了解新的 AKS 版本，AKS 发行说明页面会定期更新。 此外，还可订阅 GitHub AKS RSS 提要，该信息提要提供了有关更改和增强功能的实时更新。

AKS 遵循 N - 2 支持策略，这意味着为最新版本（N）和之前的两个次要版本提供完全支持。 为先前的第三个次要版本提供有限的平台支持。 有关详细信息，请参阅 AKS 的支持策略。

要确保 AKS 群集仍受支持，需建立持续的群集升级过程。 此过程包括在较低环境中测试新版本，并在新版本变为默认版本之前计划升级到生产环境。 此方法有助于在升级过程中保持可预测性，并将应用程序中断降到最低。 有关详细信息，请参阅 AKS 群集的升级选项。

如果群集需要更长的升级周期，请使用支持长期支持 (LTS) 选项的 AKS 版本。 如启用 LTS 选项，Microsoft 将为 Kubernetes 版本提供两年的外延支持，从而实现更长和更可控的升级周期。 有关详细信息，请参阅 AKS 支持的 Kubernetes 版本。

群集升级包括节点升级，并使用封锁和清空过程。

升级之前

最佳做法是，应始终在较低环境中进行升级和测试，以最大限度地降低生产中断的风险。 群集升级涉及 API 更改，这可能会影响 Kubernetes 部署，因此需要额外的测试。 以下资源可帮助你完成升级过程。

• 已弃用 API 的 AKS 工作簿： 在 Azure 门户的群集概述页中，选择“ 诊断并解决问题”，转到“ 创建”、“升级”、“删除”和“缩放 ”类别，然后选择 “Kubernetes API 弃用”。 此过程运行一个工作簿，用于检查群集仍在使用的已弃用 API 版本。 有关详细信息，请参阅移除已弃用 API 的使用情况。

• AKS 发行说明页： 本页提供有关新 AKS 版本和版本的综合信息。 请查看这些说明，随时了解最新更新和更改。

• Kubernetes 发行说明页： 本页提供有关最新 Kubernetes 版本的详细见解。 特别注意紧急升级说明。 它们突出显示可能影响 AKS 群集的关键信息。

• AKS 组件按版本重大变更： 下表全面概述了 AKS 组件中按版本进行的重要变更。 通过参考本指南，可以在升级过程之前主动解决任何潜在的兼容性问题。

除了这些 Microsoft 资源之外，还应考虑使用开源工具优化群集升级过程。 其中一种工具是 Fairwinds pluto，该工具可以扫描部署和 Helm 图表中已弃用的 Kubernetes API。 这些工具可帮助有效确保应用程序与最新的 Kubernetes 版本保持兼容。

升级过程

若要检查群集是否需要升级，请使用 az aks get-upgrades 命令获取 AKS 群集的可用升级版本列表。 根据结果确定群集的目标版本。

下面是一个示例：

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

示例输出：

MasterVersion  Upgrades
-------------  ---------------------------------
1.30.7         1.31.1, 1.31.2, 1.31.3

检查节点池中节点的 Kubernetes 版本，以查找需要升级的池：

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

示例输出：

Name          K8version
------------  ------------
systempool    1.30.7
usernodepool  1.30.7

手动升级

若要最大程度地减少中断并帮助确保 AKS 群集的顺利升级，请采用以下升级方法：

1. 升级 AKS 控制平面。 升级负责管理和协调群集的控制平面组件。 首先升级控制平面，以帮助在升级单个节点池之前确保兼容性和稳定性。

2. 升级系统节点池。 升级控制平面后，请升级 AKS 群集中的系统节点池。 节点池由运行应用程序工作负荷的 VM 实例组成。 通过单独升级节点池，可对支持应用程序的底层基础架构进行受控的系统升级。

3. 升级用户节点池。 升级系统节点池后，请升级 AKS 群集中的任何用户节点池。

遵循此方法，可最大限度地减少升级过程中的中断，并维护应用程序的可用性。 请执行以下步骤：

1. 使用 az aks upgrade 命令（配合 --control-plane-only 标志）仅升级群集控制平面，而不升级群集节点池：

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. 运行 az aks nodepool upgrade 命令，将节点池升级到目标版本：

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

   在节点池升级期间，AKS 会在要升级的节点中创建扩容节点，为正在升级的节点上的 Pod 配置隔离并排空，重新制作节点镜像，然后解除对 Pod 的隔离。 此过程对节点池中的其他节点重复。

可通过运行 kubectl get events 检查升级过程的状态。 有关对群集升级问题进行故障排除的信息，请参阅 AKS 故障排除文档。

在自动升级发布通道中加入集群

AKS 还提供 自动群集升级解决方案 ，使群集保持最新状态。 如果使用此解决方案，则应将其与维护时段配合使用，控制升级的时间。 升级时段必须为 4 小时或更长时间。 在发布通道中注册群集时，Microsoft 会自动管理群集及其节点池的版本和升级节奏。

群集的自动升级提供了不同的发布通道选项。 以下是建议的环境和发布通道配置：

注意事项

下表描述了各种 AKS 升级和修补方案的特征。

• 在节点映像升级过程中应用的 OS 安全修补程序可能会安装更高版本的内核，而不是安装新创建群集。

• 节点池纵向扩展使用当前与虚拟机规模集关联的模型。 应用安全修补程序并重启节点时，OS 内核会升级。

参与者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• Anthony Nevico | 首席云解决方案架构师

其他参与者：

• Rishabh Saha | 首席解决方案架构师
• Paolo Salvatori | FastTrack for Azure 首席客户工程师
• Ali Yousefi | 云解决方案架构师

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

• AKS 产品文档
• AKS 发布跟踪器
• AKS 路线图
• AKS 登陆区域加速器
• 排除 AKS 故障
• 优化 AKS 升级
• 节点 OS 升级常见问题解答
• AKS 构造集
• AKS 基线自动化
• 定义两日操作
• 区域冗余 AKS 群集实用指南

相关资源

• AKS day-2 操作指南
• AKS 会审做法