通过

AKS 升级常见问题

有关 Azure Kubernetes 服务 （AKS） 升级的常见问题解答。

升级过程和要求

是否可以将 AKS 群集直接升级到较新的 Kubernetes 版本，或者是否需要按顺序升级？

必须通过每个次要 Kubernetes 版本按顺序执行 AKS 群集升级。 不支持跳过次要版本的直接升级，除非从不支持的版本升级到受支持的版本。 AKS 在允许升级操作继续之前确保请求的 升级路径有效。

有关为群集选择升级路径以及 AKS 升级策略指南的更多建议，请参阅以下文章：

如果在 AKS 升级期间跳过次要版本，会发生什么情况？

仅当从不支持的版本升级到受支持的版本时，才允许在升级期间跳过次要版本。 请参阅 Kubernetes 版本升级，了解从不受支持的版本升级并跳过两个或更多次要版本时需要考虑的特定注意事项。

如何在升级 AKS 之前处理工作负载使用的已弃用 Kubernetes API？

Kubernetes API 会随每个新版本版本而更改。 随着 Kubernetes API 的发展，API 会定期重新组织或升级。 当 API 发展并毕业到 GA 版本时，预发行 API 版本将弃用并最终删除。 默认情况下，为了防止升级或工作负荷失败，AKS 会在升级作触发前 12 小时内验证已弃用 API 的使用，并在找到此类 API 使用情况时阻止该作。

在升级 AKS 群集之前，应确定群集中已弃用的 API 使用情况，并迁移工作负载以使用新的受支持的 API 版本。 请参阅以下文章，详细了解如何识别群集中已弃用的 API 使用情况并迁移到新的 API 版本：

是否可以升级 AKS 群集的控制平面，并且仅升级某些节点池？

可以，可以独立升级 AKS 群集的控制平面以及特定的节点池。 但是，确保控制平面与所有节点池之间的兼容性对于群集稳定性至关重要，因此控制平面和节点池之间的版本偏差遵循特定的规则和限制。 有关这些规则的详细信息以及控制平面/节点池版本差异管理的指导，请参阅以下资源：

影响和缓解

升级 AKS 群集是否会导致正在运行的应用程序停机或中断？

AKS 群集升级过程涉及对工作节点的滚动更新，该更新基于节点清空和 Pod 逐个驱逐，可能导致已部署的工作负载短暂不可用。 可以通过适当的工作负荷配置将 AKS 群集升级期间的停机时间降到最低。 通过利用多个 AKS/Kubernetes 原生功能，您可以确保在升级期间任何时刻都有足够数量的充分分布的 Pod 副本。

有关工作负荷配置的详细信息和最佳做法，以便在升级作期间最大程度地降低影响，请参阅以下文章：

StatefulSet Pod 和持久卷在 AKS 群集升级期间如何受到影响？

在 AKS 群集升级期间，StatefulSet Pods（如同所有其他 Pods）在节点升级过程中被驱逐并重新调度。 节点上运行的 CSI 驱动程序负责将永久性卷无缝重新附加到新节点，这可确保数据完整性和可用性。 此过程可最大程度地减少对有状态应用程序的中断。 有关在 AKS 中使用有状态应用程序和持久卷的详细信息，请参阅AKS 中的有状态工作负荷。

如何规划 AKS 升级以最大程度地减少工作负荷中断？

AKS 群集升级过程旨在最大程度地减少群集上运行的工作负荷的中断，但是，升级期间发生的节点清空和 Pod 逐出可能会导致中断。 同时遵循关于工作负荷配置的最佳实践，我们建议：

  • 在非工作时间或低活动期间升级。
  • 使用 AKS 计划内维护 来计划和控制群集自动升级行为。
  • 适当地缩放工作负荷，以确保有足够的副本可用于处理流量。
  • 使用 Pod 中断预算来控制关键工作负载中并发 Pod 驱逐的数量。
  • 在升级生产环境之前，先测试较低环境中的升级（例如开发/测试环境）。

有关在升级作期间尽量减少影响的指导，请参阅以下文章：

将 AKS 从免费 SKU 升级到标准 SKU 是否会导致停机？

将群集层从免费更新到标准层时，不应遇到任何停机。 此过程旨在顺利过渡，而不会中断正在运行的应用程序。 有关更新 AKS 群集层的更多指导，请参阅 更新现有 AKS 群集层。

Permissions

执行 AKS 群集升级需要哪些 Azure RBAC 权限或角色？

若要触发 AKS 群集升级，用户必须在群集资源级别分配 Azure Kubernetes 服务参与者角色。 请参阅以下文章，详细了解此角色，并进一步指导用户提供对 AKS 资源的精细访问：

备份和回滚

升级 AKS 群集之前，建议使用哪些备份策略？

在每次升级之前备份 AKS 群集并不是必需的，但拥有适当的备份和恢复功能是任何组织的运营和灾难恢复策略的重要组成部分。 可以使用 Velero 和 AKS 备份等工具来备份群集资源和数据，并保证服务尽快恢复。 有关为 AKS 群集设置备份和还原的详细指南，请参阅以下文章：

如果 AKS 升级失败或引发问题，是否可以执行回滚操作？

不支持回滚 AKS 群集升级操作。 如果升级作失败或由于某种原因未成功完成，则群集前进的路径为：

  • 解决阻止升级成功的任何问题。 有关解决升级期间可能发生的特定问题的指南，请参阅 AKS 故障排除文档 。
  • 重试群集升级操作。

如果升级成功完成，但引入了工作负载问题（例如 API 兼容性问题），建议的解决方案是在以前的版本中重新创建群集，并从之前创建的备份还原工作负荷。 AKS 建议：

  • 在继续在生产环境中继续升级之前，在较低环境中彻底验证与新 AKS 版本的工作负载兼容性（例如开发、测试）。
  • 在启动升级之前备份工作负荷和配置。 有关使用 Azure 备份的 AKS 备份/还原策略的详细指南，请参阅 AKS 备份 。

AKS 还建议实施蓝绿部署策略，这样就可以分阶段引入新的 AKS 版本，同时维护服务可用性。 有关使用此方法的详细信息，请参阅 AKS 群集的蓝绿部署 。

自动升级和维护

AKS 自动升级通道是否会自动将群集升级到最新的修补程序版本？

是的，将自动升级通道设置为 Patch 自动将群集升级到最新的可用修补程序版本，通常在以前定义的维护时段内。 这可确保集群始终获得最新的安全和稳定性补丁，而无需人工干预。 有关配置自动升级通道以及将计划内维护时段与 AKS 群集配合使用的指导，请参阅以下文章：

AKS 群集升级过程是否会重启或重新映像节点？

在 AKS 群集升级期间，节点会被重新制作映像，而不仅仅是重启。 重新映像可确保节点运行更新的 Kubernetes 版本和配置。 此过程有助于维护群集一致性和运行状况。 有关 AKS 节点升级过程的详细说明，请参阅升级 AKS 群集。

AKS 还提供使用 OS 安全修补程序通道的选项，该通道可保证工作器节点获得最新的作系统安全更新，且中断最少。 有关使用 OS 安全修补程序通道及其优势的详细信息，请参阅 在 AKS 中通过 OS 安全修补程序增强操作系统的安全性 。

什么是 AKS 计划内维护，如何使用它来控制 AKS 自动升级行为？

为了最大程度地减少对正在运行的工作负荷的影响，AKS 计划内维护允许为群集和节点操作系统映像的自动升级渠道定义特定的升级计划。 群集可以使用特定的重复周期和持续时间设置，具有一个或多个与不同升级方案相关的计划内维护配置。

有关在群集中使用 AKS 计划内维护和自动升级通道的详细信息，请参阅以下文章：

如何监视群集中的维护活动？

AKS 通信管理器允许你在维护事件之前和期间接收警报，包括自动升级操作结果以及故障情况下的指导。 有关如何为 AKS 群集设置维护相关通知的详细信息，请参阅 AKS 通信管理器 。

支持和弃用

可以持续运行不支持的 AKS Kubernetes 版本，以及升级的宽限期是多少？

AKS 在每个版本删除后提供 30 天的宽限期，在此期间，你仍会收到对群集的支持。 强烈建议监视 AKS 弃用通知，以确保群集保持在受支持的版本范围内。 宽限期结束后，运行不受支持的版本可能会导致缺乏支持，并可能暴露出安全漏洞。 有关 AKS 版本弃用、发布日历和发行说明的详细信息，请参阅以下资源：

AKS 还提供长期支持（LTS）选项，该选项扩展 Kubernetes 版本的支持窗口，以提供更多时间来规划和测试对较新的 Kubernetes 版本的升级。 有关使用 AKS LTS 的详细信息，请参阅对 AKS 版本的长期支持 。

升级运行不受支持的或明显过时版本的 AKS 群集的最佳做法是什么？

对于运行不受支持的或明显过时的 Kubernetes 版本的 AKS 群集，建议的最佳做法包括：

  1. 使用受支持的 Kubernetes 版本创建新群集。
  2. 将工作负荷迁移到 新群集，以确保它们在受支持的版本上运行。
  3. 避免跨多个版本升级。 迁移到新群集，而不是通过多个次要版本进行升级，可最大程度地降低复杂性和潜在问题。
  4. 在迁移之前备份和验证数据。
  5. 在过渡环境中执行彻底测试，以识别和解决任何兼容性问题。

在 AKS 群集升级期间是否提供待命或主动的 Microsoft 支持？

否，Microsoft仅提供对 AKS 群集升级的被动支持。 如果在升级期间需要主动或备用支持，则需要参与 Azure 事件管理服务，这些服务是独立的，并且可能涉及额外的成本。 有关 Azure 支持选项的详细信息，请参阅 Azure 支持计划 。

Helm 版本是否与较新的 AKS Kubernetes 版本兼容？

是的，Helm 版本 3 与所有受支持的 AKS Kubernetes 版本兼容。 建议使用 Helm v3 在 AKS 群集上部署和管理应用程序，以确保对最新功能的兼容性和访问权限。 有关将 Helm 与 AKS 配合使用的指导，请参阅以下资源：

是否可以使用 Terraform 升级 AKS 群集或更改 SKU 层？

虽然 Azure CLI 中保证对所有正式版 AKS 功能的支持，但对某些 GA 功能的 Terraform 支持可能会滞后，并且受 Terraform 提供程序开发约束的约束。 建议检查 Terraform Azure 提供程序文档 ，了解特定功能的支持状态。

升级到版本 1.30 或更高版本后，AKS 群集是否支持 Beta Kubernetes API？

从 Kubernetes 版本 1.30 和 1.27 LTS 开始，在 AKS 群集中默认禁用 Beta API，这与 AKS 支持策略一致。 此外，自 2024 年 11 月 30 日起，在使用 Kubernetes 版本 1.28 和 1.29 创建的 AKS 群集中也将禁用 Beta API。 有关详细信息，请参阅升级 AKS 群集。

网络和安全性

谁为 AKS 群集创建入站 NSG 规则，为什么需要这些规则？

AKS 根据群集中部署的服务自动管理网络安全组（NSG）配置，以允许 Internet 访问与这些工作负载关联的公共 IP。 AKS 配置的入站规则对于启用对集群中已部署服务的外部访问至关重要。 手动修改托管 NSG 配置可能会影响服务可用性。 有关 AKS 网络概念的详细信息，请参阅 AKS 中应用程序的网络概 念。