通过 Azure Kubernetes 服务 (AKS) 中的节点池版本回滚功能,可以在 Kubernetes 升级后从意外行为中恢复。 如果出现问题,可以将节点池回滚到以前的 Kubernetes 版本和节点映像组合,确保业务连续性并最大限度地减少停机时间。 本文介绍了何时以及如何使用回退功能,其能力和限制,以及回退后行动的最佳实践。
先决条件
- Azure CLI版本 2.64.0 或更高版本。 使用
az --version命令查找版本。 如果需要安装或升级,请参阅 Install Azure CLI。 -
aks-previewAzure CLI 扩展已安装并更新到最新版本。 - API 版本
2025-08-02-preview或更高版本。
安装 aks-preview Azure CLI 扩展
重要
AKS 预览功能可在自助服务和自愿选择的基础上启用。 预览版按“现状”和“视供应情况”提供,它们不包括在服务级别协议和有限保证范围内。 AKS 预览功能是由客户支持尽最大努力部分覆盖。 因此,这些功能并不适合用于生产。 有关详细信息,请参阅以下支持文章:
使用aks-preview和az extension add命令安装或更新az extension update扩展。
# Install the aks-preview extension
az extension add --name aks-preview
# Update the aks-preview extension
az extension update --name aks-preview
节点池版本回滚的支持功能
节点池版本回滚功能支持以下功能:
| 功能 | 说明 |
|---|---|
| 还原版本 | 将 Kubernetes 和节点映像版本还原到其以前的状态。 |
| 手动触发器,自动执行 | 回滚需要手动启动,但触发后,系统会自动处理整个回滚过程,而无需进一步干预。 |
| 节点池兼容性 | 适用于所有类型的节点池,包括虚拟机(VM)池和基于虚拟机规模集(VMSS)的节点池。 |
| 操作系统支持 | 与所有操作系统(OS)库存单元(SKU)兼容,包括 Ubuntu、Azure Linux 和Windows池。 |
| 简化的过程 | 不需要快照管理。 |
节点池回滚限制和注意事项
使用节点池回滚功能时,请记住以下限制:
- 仅限版本更改。 其他节点池的更改不会被还原。
- 回滚期间不允许并发操作。
- 如果已配置,则必须在回滚之前禁用群集自动升级。 否则,自动升级过程可能会在回滚完成后再次自动升级节点池。
- 仅在升级完成后的 7 天内可用。
- 无法执行连续回滚以返回多个版本。
- 回滚不支持还原 OS SKU 更改。 如果更改了节点池的 OS SKU(例如,从 Ubuntu 更改为 Azure Linux),则回滚会尝试还原属于其他 OS SKU 且被拒绝的以前的节点映像版本。 若要还原 OS SKU 更改,请改用
az aks nodepool update --os-sku该命令。
使用节点池回滚时,请记住以下注意事项:
| 安全隐患 | 运行考虑事项 |
|---|---|
| • 漏洞泄露:回滚会从较新版本中删除安全修补程序和更新。 因此,我们建议仅在解决问题期间暂时使用回退,然后尽快重新升级。 | • 服务中断:回滚进程可能会导致临时工作负荷中断。 • 资源可用性:确保回退操作有足够的容量。 • 测试要求:计划修复基础问题,然后再再次尝试升级。 |
为何使用回滚
回滚为生产环境提供关键恢复机制:
- 业务连续性:在升级导致意外问题时尽量减少停机时间
- 风险缓解:无需复杂的恢复过程即可快速还原已知良好的配置
- 简化恢复:避免手动干预或从备份重新生成群集
何时使用节点池回滚
在以下情况下,请考虑回滚作为恢复选项:
- 发生升级失败:基础结构问题、资源约束或兼容性问题阻止成功升级。
- 应用程序中断:工作负载在较新的 Kubernetes 版本中遇到严重故障或数据损坏。
- 性能下降:新版本会导致不可接受的延迟、吞吐量问题或资源消耗。
- 测试差距浮出水面:生产中出现了未被预生产测试发现的问题。
节点池回滚工作流
下图演示了节点池回滚工作流:
回滚过程会将节点池中的所有节点还原到其以前的版本状态。 工作流的关键方面包括:
- 全有或全无方法:所有节点必须成功还原到以前的版本,才算回滚成功完成。 如果任何节点无法回滚,则整个操作将失败,以便清楚地显示集群的状态,类似于升级操作。
- 进度跟踪:使用 Azure 活动日志监视操作历史记录的回滚状态,实时更新可通过操作状态 API 完成。
回滚节点池版本
重要
回滚节点池版本时,请记住以下信息:
- 长期保留旧版本会增加安全风险,最终可能会由于版本偏斜限制而阻止升级。 将回滚视为临时恢复机制,而不是永久解决方案。
- 使用 REST API 时,可以先调用 “获取升级配置文件 API”来检索最近使用的版本。 使用此信息在回滚请求中指定目标版本。
使用
az aks nodepool rollback命令,回滚节点池版本。 以下示例回滚资源组myNodePool中名为myAKSCluster的 AKS 群集中的节点池myResourceGroup:az aks nodepool rollback --name myNodePool --resource-group myResourceGroup --cluster-name myAKSCluster
监视节点池回滚状态
可以使用以下方法来监视节点池回滚操作的状态,并验证回滚是否成功。
回滚后的最佳做法
成功回滚节点池后,请使用以下最佳做法来确保稳定性和安全性:
- 调查根本原因:确定在尝试另一个升级之前升级失败的原因。 查看应用程序日志、资源指标和兼容性要求。
- 在非生产环境中进行测试:在开发或过渡环境中验证较新版本以重现并解决问题,然后再再次升级生产。
-
规划重新升级:不要无限期地保留回退版本。 计划重新升级以维护安全修补程序和支持:
- 对于关键安全问题:在验证修复后的几天内重新升级。
- 对于应用程序兼容性问题:在代码调整后的几周内重新升级。
- 建议的最大时间范围:30 天,以避免累积安全漏洞。
常见问题 (FAQ)
是否可以在节点池回滚期间执行其他操作?
否,回滚必须在进行其他作业之前完成。 若要执行不同的操作,请先中止回滚。
节点池回滚是否会一并恢复 Kubernetes 版本和节点映像?
是的,回滚将恢复到最近使用的 Kubernetes 版本及其对应的节点映像。 如果这两个组件都已更改,则系统会使用该版本的最后一个兼容节点映像还原以前的 Kubernetes 版本。
是否可以仅回滚节点镜像而无需更改节点池版本?
是的,如果在过去七天内仅执行节点映像更新(不升级节点池版本),则回滚会还原以前的虚拟硬盘(VHD)映像,同时维护相同的 Kubernetes 版本。
是否可以回滚到不再受支持的版本?
否,不能回滚到 AKS 不再支持的 Kubernetes 版本。 例如,如果节点池的版本为 1.27.9(现在不受支持),并且已升级到 1.28.5,则无法回滚到 1.27.9,因为它不再位于受支持的版本列表中。 请始终检查 AKS Kubernetes 版本支持策略 以验证版本可用性。
在执行节点池回滚之前,是否需要禁用自动升级?
是的,如果您的群集已启用自动升级,则必须在进行回滚之前禁用它。 此外,如果群集包含在 Azure Kubernetes Fleet Manager 自动升级配置文件中的更新组中,则必须在执行回滚之前从更新组中删除群集。 否则,自动升级过程可能会在回滚完成后再次自动升级节点池。
是否可以在更改 OS SKU(例如,从 Ubuntu 到 Azure Linux)之后回滚?
否。 节点池回滚仅限于版本更改,不会还原 OS SKU 更改。 从一个 OS SKU 迁移到另一个 OS SKU(例如,Ubuntu 到 Azure Linux)后,以前的节点映像版本属于旧的 OS SKU,并且与当前配置不兼容。 回滚操作会拒绝以前的映像版本,并出现类似于以下错误:
NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'
若要还原 OS SKU,请将 az aks nodepool update 命令与参数一起使用 --os-sku 。 有关详细信息,请参阅回滚 OS 版本。
相关内容
若要详细了解 AKS 中的节点池升级,请参阅以下文章:
- 在 Azure Kubernetes 服务 (AKS) 中配置蓝绿节点池升级
- 为Azure Kubernetes 服务 (AKS)节点池配置滚动升级
- Azure Kubernetes 服务 (AKS) 中的自动升级节点操作系统映像