你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

项目
05/14/2024

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

更新的背景和类型

AKS 有三种类型的更新，且每种类型的更新都依赖于前一种：

更新类型	升级频率	支持计划内维护	支持的操作方法	目标	文档链接
节点 OS 安全修补程序	夜间	是	自动（每周）、手动/非托管（夜间）	节点	自动升级节点映像
节点映像版本升级	Linux：每周 Windows：每月	是	自动、手动	节点池	AKS 节点映像升级
Kubernetes 版本（群集）升级	季度	是	自动、手动	群集和节点池	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 版本。

升级前的注意事项

总体群集影响

就地升级（节点和群集）在升级过程中会影响 Kubernetes 环境的性能。通过正确配置 Pod 中断预算、节点激增配置以及适当的规划，可将这种影响降低到最小。
使用蓝/绿更新策略而非就地升级，可消除对群集性能造成的任何影响，但同时会增加成本和复杂性。
无论采用何种升级和修补策略，都需要为群集提供可靠的测试和验证过程。首先对较低的环境进行修补和升级，然后执行维护后验证，检查群集、节点、部署和应用程序运行状况。

AKS 工作负载最佳做法

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

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

警告

Kubernetes API 会阻止在滚动节点映像升级中发生的必要隔离和排空，因此配置错误的 PDB 可能会阻止升级过程。此外，如果同时移动过多 Pod，可能会导致应用程序中断。 PDB 配置可降低此风险。
检查可用计算和网络限制。 通过 Azure 门户中的配额页或使用 az quota 命令验证 Azure 订阅中的可用计算和网络限制。请务必检查节点的计算和网络资源，尤其是 VM vCPU，以及虚拟机和虚拟机规模集的数量。如果接近限制，请在升级之前请求增加配额。
检查节点子网中的可用 IP 空间。 更新期间，会在群集中创建更多的激增节点，并将 Pod 移动到这些节点。因此，请务必监视节点子网中的 IP 地址空间，以确保有足够的地址空间进行这些更改。不同的 Kubernetes 网络配置有不同的 IP 要求。首先，请查看以下注意事项：
- 升级期间，节点 IP 数会随激增值增加而增加。（最小激增值为 1）。
- 基于 Azure CNI 的群集会将 IP 地址分配给各个 Pod，因此需要有足够的 IP 空间进行 Pod 移动。
- 升级期间，群集将继续运行。请确保留有足够的 IP 空间以允许节点缩放（如已启用）。
设置多个环境。 建议设置单独的环境（如开发、过渡和生产环境），以便在将更改部署到生产环境之前对其进行测试和验证。
调整激增升级值。 AKS 的激增值默认为 1，意味着在升级过程中一次只创建一个额外的节点。可通过增加此值来提高 AKS 升级的速度。对于对中断敏感的工作负载，建议的最大值为 33%。更多信息，请参阅自定义节点激增升级。
优化节点排空超时。 节点排空超时指定群集在尝试在更新的节点上重新计划 Pod 时等待的最长时间。此参数的默认值为 30 分钟。对于难以重新计划 Pod 的工作负荷，调整此默认值会很有帮助。
计划和安排维护时段。 升级过程可能会影响 Kubernetes 群集的整体性能。请在高峰使用时段之外计划就地升级过程，并监视群集性能，以确保适当调整大小（尤其是在更新过程中）。
检查群集中的其他依赖项。 在操作中，Kubernetes Operator 通常将其他工具（例如 KEDA 缩放程序、Dapr 和服务网格）部署到 Kubernetes 群集。规划升级过程时，请检查正在使用的组件的发行说明，以确保与目标版本兼容。

管理节点映像每周更新。

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

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

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

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

自动节点映像升级

一般而言，大多数群集都应使用 NodeImage 更新通道。该通道每周提供更新的节点映像 VHD，并根据群集的维护时段进行更新。

可用的通道包括：

None。不会自动应用任何更新。
Unmanaged。 OS 每晚都会应用 Ubuntu 和 Azure Linux 更新。须单独管理重新启动。 AKS 既无法测试这一情况，也无法控制这一情况的节奏。
SecurityPatch。经过 AKS 测试、完全托管并应用安全部署实践的 OS 安全修补程序。其中不包含任何 OS 错误修复，只包含安全更新。
NodeImage。 AKS 将使用新修补的 VHD 来更新节点，其中包含每周一次的安全修复和 bug 修复。这经过了充分的测试，并使用安全部署实践进行了部署。有关当前部署的节点映像的实时信息，请参阅 [发布跟踪器中的 AKS 节点映像部分][release-tracker]。

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

如果选择 Unmanaged 更新通道，则需要使用 kured 等工具管理重新启动过程。 Unmanaged 不具备 AKS 提供的安全部署实践，在维护时段下也不起作用。如果选择 SecurityPatch 更新通道，则可以以每周为单位频繁地应用更新。此修补程序级别要求 VHD 存储在资源组中，因此会产生少许费用。通过设置与最适合工作负载节奏相一致的适当 aksManagedNodeOSUpgradeSchedule 设置来控制何时应用 SecurityPatch。有关详细信息，请参阅创建维护时段。如果还需要新节点映像 (VHD) 通常附带的错误修复，则需要选择 NodeImage 通道而不是 SecurityPatch通道。

最佳做法是，使用 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 添加维护时段配置。

理想情况下，此配置将作为群集“基础结构即代码”部署的一部分进行部署。

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

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

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

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

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

重要

如果节点池中节点数量较多，但未配置节点激增，则可能不会触发自动升级事件。只有当估计的总升级时间在 24 小时内时，节点池中的节点映像才会升级。

在这种情况下，可以考虑以下方法之一：

如果 vCPU 配额几乎已满，并且无法增加 vCPU 配额，请将节点拆分为不同的节点池
如果 vCPU 配额足够，则配置节点激增以减少估计的升级时间

可以通过 Azure 活动日志或通过查看群集上的资源日志来检查升级事件的状态。

可以使用 Azure 事件网格订阅 Azure Kubernetes 服务 (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.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

使用 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

示例输出：

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

群集升级

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.26.6         1.27.1, 1.27.3

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

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

示例输出：

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

手动升级

要最大限度地减少中断并帮助确保 AKS 群集顺利升级，请遵循以下升级方法：

升级 AKS 控制平面。 首先升级 AKS 控制平面。此步骤包括升级负责管理和协调群集的控制平面组件。在升级各个节点池之前，首先升级控制平面有助于确保兼容性和稳定性。
升级系统节点池。 升级控制平面后，请升级 AKS 群集中的系统节点池。节点池由运行应用程序工作负载的虚拟机实例组成。通过单独升级节点池，可对支持应用程序的底层基础架构进行受控的系统升级。
升级用户节点池。 升级系统节点池后，请升级 AKS 群集中的任何用户节点池。

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

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

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

运行 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 会自动管理群集及其节点池的版本和升级节奏。

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

环境	升级通道	说明
生产	`stable`	为获得稳定性和版本成熟度，请为生产工作负载使用稳定或常规通道。
过渡、测试、开发	与生产相同	为确保测试能够指明要将生产环境升级到的版本，请使用与生产相同的发布通道。
Canary	`rapid`	要测试最新的 Kubernetes 版本和新的 AKS 功能或 API，请使用 `rapid` 通道。将 `rapid` 通道中的版本提升到用于生产的通道后，可以缩短面市时间。

注意事项

下表描述了各种 AKS 升级和修补场景的特点：

场景	用户发起	Kubernetes 升级	OS 内核升级	节点映像升级
安全修补	否	否	是，重新启动后	是
群集创建	是	可能	是，如果更新的节点映像使用更新的内核	是，相对于现有群集（如果新版本可用）
控制平面 Kubernetes 升级	是	是	否	否
节点池 Kubernetes 升级	是	是	是，如果更新的节点映像使用更新的内核	是的，如果新版本可用
节点池纵向扩展	是	否	No	否
节点映像升级	是	否	是，如果更新的节点映像使用更新的内核	是
群集自动升级	否	是	是，如果更新的节点映像使用更新的内核	是的，如果新版本可用

在节点映像升级过程中应用的 OS 安全修补程序可能会安装更高版本的内核，而不是安装新创建群集。
节点池纵向扩展使用当前与虚拟机规模集关联的模型。应用安全修补程序并重启节点时，OS 内核会升级。

作者

本文由 Microsoft 维护，它最初是由以下贡献者撰写的。

主要作者：

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

其他参与者：

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

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

通过

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

更新的背景和类型

更新类型

升级前的注意事项

总体群集影响

AKS 工作负载最佳做法

管理节点映像每周更新。

自动节点映像升级

手动节点更新过程

群集升级

升级之前

升级过程

手动升级

在自动升级发布通道中注册群集

注意事项

作者

后续步骤

反馈

其他资源

通过

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

更新的背景和类型

更新类型

升级前的注意事项

总体群集影响

AKS 工作负载最佳做法

管理节点映像每周更新。

自动节点映像升级

手动节点更新过程

群集升级

升级之前

升级过程

手动升级

在自动升级发布通道中注册群集

注意事项

作者

后续步骤

相关资源

反馈

其他资源