閱讀英文

共用方式為

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

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 通道?

在选择SecurityPatchNodeImage通道时,有两个重要的注意事项。

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

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

  • 使用带参数的 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 自动升级通道

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

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 快照服务下载所需的安全修补程序和更新。

如何知道节点上是否应用了 SecurityPatchNodeImage 升级?

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 门户的节点标签视图下出现:

Azure 门户中 AKS 群集的节点页的屏幕截图。节点映像版本的标签清楚地显示了基本节点映像和最新应用的安全修补程序日期。