Azure Kubernetes群集节点OS镜像更新策略概览-CFANZ编程社区

Azure Kubernetes群集节点OS镜像更新策略概览

一般在使用Azure Kubernetes群集时，我们最好熟悉群集的各种更新过程，这样可以避免因为服务升级造成业务稳定性的下降。Azure Kubernetes Services中的升级一般可以分为如下两部分内容：

Azure Kubernetes服务升级：所谓的Azure Kubernetes服务升级就是Kubernetes版本升级。
Azure Kubernetes服务节点OS镜像升级：节点OS镜像升级时指AKS的Work Node升级策略。

我们今天主要围绕Azure Kubernetes服务节点OS镜像升级来进行讨论。在使用AKS的过程中我们会发现，节点OS安全更新的发布速度要快于Kubernetes补丁或次要版本的更新速度。节点OS升级可以为我们在使用AKS的过程中，提供更多的灵活性，同时我们也可以为节点OS安全更新配置自定义策略。

一般情况下，我们强烈建议同时使用群集级自动升级和节点 OS 自动升级通道。可通过应用两组单独的维护时段来微调计划 - 对群集自动升级通道应用 aksManagedAutoUpgradeSchedule，对节点 OS 自动升级通道应用 aksManagedNodeOSUpgradeSchedule。这样，通过灵活的控制这两组参数，来控制我们AKS群集的升级策略。

一般在创建Azure Kubernetes时，如果我们不显示的指定群集节点OS升级策略，则群集节点OS升级策略默认为NoImage，具体我们可以通过如下CLI来进行查看：

az aks show -n dhl-aks -g workclient --query "autoUpgradeProfile"

Azure Kubernetes群集节点OS镜像更新策略概览_安全更新

对于NoImage的更新通道，AKS将使用新修补的VHD文件来更新AKS群集节点，新修补的VHD中，包含每周一次的安全更新和bug修复。但是对于NoImage的更新时会产生中断的，也就意味着，节点OS更新的过程中，系统会有一个重启的过程。那是否有什么方式来避免这一问题，或者可以在计划的时间内进行节点OS修复呢？答案肯定是可以的，我们可以通过修改节点OS镜像的更新通道，来控制不同的更新策略，具体可选的更新通道参考如下：

通道	说明	特定于 OS 的行为
None	节点不会自动应用安全更新。这意味着你对安全更新全权负责。	空值
Unmanaged	系统将通过 OS 内置修补基础结构自动应用 OS 更新。新分配的计算机最初处于未修补状态。 OS 的基础结构会在某个时候对其进行修补。	Ubuntu 和 Azure Linux（CPU 节点池）大约每天 06:00 UTC 左右通过无人参与升级/dnf 自动应用安全修补程序。 Windows 不会自动应用安全修补程序，因此该选项的行为等效于 None。
SecurityPatch	此通道处于预览状态，要求启用功能标志 NodeOsUpgradeChannelPreview。有关详细信息，请参阅先决条件部分。 AKS 定期使用映像维护程序中标记为“仅安全性”的修补程序更新节点的虚拟硬盘 (VHD)。将安全修补程序应用于节点时，可能会出现中断。应用修补程序后，VHD 将会更新，现有计算机将升级到该 VHD，从而遵循维护时段和激增设置。此选项会产生在节点资源组中托管 VHD 的额外成本。如果使用此通道，默认情况下将禁用 Linux 无人参与升级。	Azure Linux 在启用了 GPU 的 VM 上不支持此通道。 SecurityPatch 适用于已弃用的补丁版本，只要次要 Kubernetes 版本仍然受支持。
NodeImage	AKS 将使用新修补的 VHD 来更新节点，其中包含每周一次的安全修复和 bug 修复。在维护时段和激增设置之后，对新 VHD 的更新是中断性的。选择此选项时不会产生额外的 VHD 成本。如果使用此通道，默认情况下将禁用 Linux 无人参与升级。节点映像升级适用于已弃用的修补程序版本，只要仍然支持次要 Kubernetes 版本即可。

我们参考上述的策略并结合具体业务的实际情况，来设计AKS群集节点OS镜像的更新策略，除此之外，我们也要考虑的一点是群集节点的更新节奏，具体大家可以参考如下：

通道	更新所有权	默认节奏
Unmanaged	OS 驱动的安全更新。 AKS 无法控制这些更新。	对于 Ubuntu 和 Azure Linux，在每晚大约凌晨 6 点 (UTC)。对于 Windows，每月一次。
SecurityPatch	AKS	每周。
NodeImage	AKS	每周。