自动升级节点操作系统映像

2025/06/16

AKS 提供了多个专用于及时节点级 OS 安全更新的自动升级通道。此通道不同于群集级别的 Kubernetes 版本升级并将取代后者。

节点 OS 自动升级与群集自动升级之间的交互

节点级 OS 安全更新的发布快于 Kubernetes 补丁或次要版本更新。节点 OS 自动升级通道授予你灵活性，并为节点级 OS 安全更新启用自定义策略。然后，可以为群集级 Kubernetes 版本自动升级选择单独的计划。最好同时使用群集级自动升级和节点 OS 自动升级通道。通过为群集自动升级通道应用两组单独的 - aksManagedAutoUpgradeSchedule，为节点操作系统自动升级通道使用 aksManagedNodeOSUpgradeSchedule，可以对计划进行微调。

用于节点 OS 映像升级的通道

所选通道将决定升级的时间。对节点 OS 自动升级通道进行更改时，这些更改最多需要 24 小时就会生效。

注意

从一个通道切换到另一个通道后，就会触发重镜像，导致节点滚动。
节点级 OS 映像自动升级不会影响群集的 Kubernetes 版本。从 API 版本 2023-06-01 开始，创建的任何新群集的默认值均为 NodeImage。

有以下升级通道可用。你可选择以下选项之一：

通道	说明	特定于 OS 的行为
`None`	节点不会自动应用安全更新。这意味着你对安全更新全权负责。	空值
`Unmanaged`	系统将通过 OS 内置修补基础结构自动应用 OS 更新。新分配的计算机最初处于未修补状态。 OS 的基础结构会在某个时候对其进行修补。	Ubuntu 和 Azure Linux（CPU 节点池）大约每天 06:00 UTC 左右通过无人参与升级/dnf 自动应用安全修补程序。 Windows 不会自动应用安全修补程序，因此该选项的行为等效于 `None`。需要使用 kured 之类的工具来管理重启过程。
`SecurityPatch`	经过 AKS 测试、完全托管并应用安全部署做法的 OS 安全修补程序。 AKS 会定期使用映像维护程序中标记为“仅安全性”的修补程序来更新节点的虚拟硬盘 (VHD)。将安全修补程序应用于节点时，可能会出现中断。但是，AKS 仅会在必要时重新映像节点，例如某些内核安全包，从而限制中断。应用修补程序后，VHD 将会更新，现有计算机将升级到该 VHD，从而遵循维护时段和激增设置。如果 AKS 决定不需要对节点重置映像，则会在没有耗尽 Pod 的情况下修补节点，并且不执行任何 VHD 更新。此选项会产生在节点资源组中托管 VHD 的额外成本。如果使用此通道，默认情况下将禁用 Linux 无人参与升级。	Azure Linux 在启用了 GPU 的 VM 上不支持此通道。只要次要 Kubernetes 版本仍然受支持，`SecurityPatch` 就适用于已弃用的 Kubernetes 修补程序版本。
`NodeImage`	AKS 将使用新修补的 VHD 来更新节点，其中包含每周一次的安全修复和 bug 修复。在维护时段和激增设置之后，对新 VHD 的更新是中断性的。选择此选项时不会产生额外的 VHD 成本。如果使用此通道，默认情况下将禁用 Linux 无人参与升级。只要群集 k8s 次要版本仍受支持，就支持节点映像升级。节点映像经过 AKS 测试、完全托管，并采用安全部署做法进行应用。

选择什么 - SecurityPatch 通道或 NodeImage 通道？

在选择SecurityPatch或NodeImage通道时，有两个重要的注意事项。

资产	NodeImage 通道	SecurityPatch 通道	推荐频道
`Speed of shipping`	典型的新 VHD 的生成、测试、发布和推出时间线，按照安全部署惯例，可能需要大约 2 周。尽管在 CVE 的情况下，可视具体情况加速推出。通过发布跟踪器可以监视新 VHD 到达一个区域的具体时间点。	即使采用安全部署做法，SecurityPatch 版本也相对较 `NodeImage`快。 SecurityPatch 在 Linux 环境中具有“实时修补”的优势，修补会导致选择性的“重镜像”，并且不会在每次应用修补程序时重镜像。如果发生重镜像，则由维护时段控制。	`SecurityPatch`
`Bugfixes`	除了安全性修补程序外，还包含 Bug 修补程序。	严格来说，只携安全性修补程序。	`NodeImage`

使用带参数的 az aks create 命令 --node-os-upgrade-channel 在新群集上设置节点 OS 自动升级通道。以下示例将节点 OS 自动升级通道设置为 SecurityPatch。

export RANDOM_SUFFIX=$(openssl rand -hex 3)
export RESOURCE_GROUP="myResourceGroup$RANDOM_SUFFIX"
export AKS_CLUSTER="myAKSCluster$RANDOM_SUFFIX"
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $AKS_CLUSTER \
    --node-os-upgrade-channel SecurityPatch \
    --generate-ssh-keys

在现有群集上设置节点 OS 自动升级通道

Azure CLI
Azure 门户

使用 az aks update 命令和 --node-os-upgrade-channel 参数在现有群集上设置节点操作系统自动升级通道。以下示例将节点 OS 自动升级通道设置为 SecurityPatch。

az aks update --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --node-os-upgrade-channel SecurityPatch

结果：

{
  "autoUpgradeProfile": {
      "nodeOsUpgradeChannel": "SecurityPatch"
  }
}

更新所有权和日程安排

默认节奏意味着没有应用计划内维护时段。

通道	更新所有权	默认节奏
`Unmanaged`	OS 驱动的安全更新。 AKS 无法控制这些更新。	对于 Ubuntu 和 Azure Linux，在每晚大约凌晨 6 点 (UTC)。对于 Windows，每月一次。
`SecurityPatch`	经过 AKS 测试、完全托管并应用安全部署做法。有关详细信息，请参阅 Azure 上 Canonical 工作负载增强的安全性和复原能力。	通常比每周快，AKS 决定了节奏。
`NodeImage`	经过 AKS 测试、完全托管并应用安全部署做法。有关发布的实时详细信息，请查看发布跟踪器中的 AKS 节点映像	每周。

注意

虽然 Windows 安全更新每月发布一次，但使用 Unmanaged 通道不会自动将这些更新应用到 Windows 节点。如果选择 Unmanaged 通道，则需要管理 Windows 节点的重启过程。

节点通道已知限制

目前，将群集自动升级通道设置为 node-image时，它还会自动将节点 OS 自动升级通道设置为 NodeImage。如果群集自动升级通道为node-image，则无法更改节点 OS 自动升级通道的值。若要设置节点 OS 自动升级通道的设定值，请确保群集自动升级通道值不是 node-image。
Windows OS 节点池不支持 SecurityPatch 通道。

注意

对 SecurityPatch 通道使用 CLI 2.61.0 或更高版本。

节点 OS 计划内维护时段

节点操作系统自动升级的计划维护从指定的维护时段开始。

注意

为确保正常运行，请使用 4 小时或更长时间的维护时段。

有关计划内维护的详细信息，请参阅使用计划内维护为 Azure Kubernetes 服务 (AKS) 群集安排维护时段。

节点操作系统自动升级常见问题解答

如何在群集上检查当前 nodeOsUpgradeChannel 值？

请运行 az aks show 命令并检查“autoUpgradeProfile”，以确定将 nodeOsUpgradeChannel 设置为什么值：

az aks show --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --query "autoUpgradeProfile"

结果：

{
  "nodeOsUpgradeChannel": "SecurityPatch"
}

如何监视节点 OS 自动升级的状态？

要查看节点 OS 自动升级的状态，请在群集上查找活动日志。还可查找升级 AKS 群集中所述的特定升级相关事件。 AKS 还会发出与升级相关的事件网格事件。

我可以在群集自动升级通道设置为 `node-image` 时，更改节点 OS 自动升级通道值吗？

不是。目前，将群集自动升级通道设置为 node-image时，它还会自动将节点 OS 自动升级通道设置为 NodeImage。群集的自动升级通道为 node-image 时，您无法更改节点操作系统的自动升级通道值。若要更改节点 OS 自动升级通道值，请确保群集自动升级通道不是 node-image。

为什么建议 `SecurityPatch` 通过 `Unmanaged` 通道使用？

在 Unmanaged 通道上，AKS 无法控制如何以及何时交付安全修补程序。通过 SecurityPatch，安全修补程序已经过全面测试，并遵循安全部署做法。 SecurityPatch 还遵循维护时段。更多详细信息，请参阅 Azure 上 Canonical 工作负载增强的安全性和复原能力。

`SecurityPatch` 是否始终导致节点的重置映像？

AKS 仅在绝对必要时才限制重置映像，例如，某些内核包可能需要重置映像才能完全应用。 SecurityPatch 旨在尽可能减少中断。如果 AKS 决定不需要对节点重置映像，则将在没有耗尽 Pod 的情况下实时修补节点，并且在这种情况下，不会执行任何 VHD 更新。

为什么 `SecurityPatch` 通道需要访问 `snapshot.ubuntu.com` 终结点？

使用 SecurityPatch 通道时，Linux 群集节点必须从 ubuntu-snapshots-on-azure-ensuring-predictability-and-consistency-in-cloud-deployments 中所述的 ubuntu 快照服务下载所需的安全修补程序和更新。

如何知道节点上是否应用了 `SecurityPatch` 或 `NodeImage` 升级？

kubectl get nodes --show-labels运行以下命令，列出群集中的节点及其标签。

在返回的标签中，你应该看到类似于以下输出的行：

kubernetes.azure.com/node-image-version=AKSUbuntu-2204gen2containerd-202410.27.0-2024.12.01

此处，基本节点映像版本为 AKSUbuntu-2204gen2containerd-202410.27.0。如果适用，通常遵循安全修补程序版本。在上面的示例中，它是 2024.12.01。

同样的详细信息也会在 Azure 门户的节点标签视图下出现：

共用方式為