Azure Kubernetes 服务 (AKS) 中支持的 Kubernetes 版本

Kubernetes 社区大约每 4 个月发布次要版本。

次要版本包括新增功能和改进。 补丁发布更为频繁（有时每周都会发布），适用于次要版本中的关键 Bug 修复。 修补程序版本包括针对安全漏洞或主要 bug 的修复。

Kubernetes 对每个版本使用标准的语义化版本控制方案：

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

版本中的每个编写表示与前一版本的一般兼容性：

• 当存在不兼容的 API 更新或者后向兼容性可能损坏时，表示主要版本变化。
• 当功能更新与其他次要版本向后兼容时，表示次要版本变化。
• 当进行向后兼容的 bug 修复时，表示修补程序版本变化。

确保运行你正在运行的次要版本的最新修补程序版本。 例如，如果你的生产群集使用 1.29.1，而 1.29.2 是 1.29 次要版本可用的最新补丁版本，那么你应尽快升级到 ，确保你的群集得到全面的修补并受到支持。1.29.2

在 AKS Kubernetes 发布日历上查看即将推出的版本发布。 若要查看区域发布状态和版本发行说明的实时更新内容，请访问 AKS 发布状态网页。 若要详细了解发布状态网页，请参阅 AKS 发布跟踪器。

对于过去的发布历史记录，请参阅 Kubernetes 历史记录。

LTS 版本

如果想要直观地查看此信息，下方提供了一个甘特图，其中显示了所有当前版本：

在升级到任何可用的次要版本之前，请注意以下重要更改：

通过 AKS，无需指定确切的修补程序版本即可创建群集。 在不指定修补程序的情况下创建群集时，群集将运行次要版本的最新 GA 修补程序。 例如，如果您创建一个包含 1.29 和 1.29.2 的群集，并且 1.29.2 是最新的 GA 可用补丁，则您的群集将使用 创建。 如果要在同一个次要版本中升级补丁版本，请使用 自动升级。

若要查看使用的修补程序，请运行 az aks show --resource-group myResourceGroup --name myAKSCluster 命令。 currentKubernetesVersion 属性显示整个 Kubernetes 版本。

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.chinaeast2.cx.prod.service.azk8s.cn",
  "currentKubernetesVersion": "1.29.2",
}

AKS 定义了一个正式发布版 (GA)，所有 SLO 或 SLA 衡量方案都启用了此版本，并且可在所有区域提供。 AKS 支持三个 Kubernetes GA 次要版本：

• AKS 中发布的最新 GA 次要版本（我们将其称为 N）。
• 以前的两个次要版本。
  • 每个受支持的次要版本可在给定时间内支持任意数量的修补程序。 如果检测到关键的 CVE 或安全漏洞，AKS 将保留弃用修补程序的权利。 如需了解修补程序可用性和任何临时弃用，请参阅版本发布说明，并访问 AKS 发布状态网页。

AKS 可能还支持预览版本，这些版本带有明确的标签，使用时需遵守预览版条款和条件。

AKS 仅为常规受支持的版本之后的一个 Kubernetes GA 次要版本提供平台支持。 AKS 上的 Kubernetes 版本的平台支持窗口称为“N-3”。 有关详细信息，请参阅平台支持策略。

AKS 上 Kubernetes 次要版本的受支持窗口称为“N-2”，其中 N 指的是最新版本，这意味着还支持两个以前的次要版本。

例如，在 AKS 引入 1.29 版本的当前，会为以下版本提供支持：

引入新的次要版本后，最早次要版本会被弃用并删除。 例如，假设当前支持的次要版本列表为：

1.29
1.28
1.27

当 AKS 发布 1.30 时，所有 1.27 版本在 30 天后不再受到支持。

AKS 可基于给定次要版本的上游社区版本可用性支持任意数量的修补程序。 AKS 保留在任何给定时候因 CVE 或潜在 bug 问题而弃用其中任何修补程序的权利。 始终鼓励对次要版本使用最新的修补程序。

平台支持策略是用于某些不受支持的 Kubernetes 版本的缩减支持计划。 在平台支持期间，客户将仅收到 Azure 提供的 AKS/Azure 平台相关问题的支持。 与 Kubernetes 功能和组件相关的任何问题不受支持。

在群集下降到 n-4 之前，平台支持策略适用于 n-3 版本（其中 n 是受支持的最新 AKS GA 次要版本）。 例如，当 v1.29 是最新的 GA 版本时，Kubernetes v1.26 被视为平台支持。 但是，在 v1.30-GA 版本中，v1.26 应自动升级到 v1.27。 如果你正在运行 n-2 版本，那么当它变成 n-3 时，它也会被弃用，你需要执行平台支持策略。

AKS 依赖于 Kubernetes 的版本和补丁，这是一个开源项目，仅支持 3 个次要版本的滑动窗口。 AKS 只能保证为上游维护的版本提供完全支持。 由于上游不再生成补丁，AKS 可以不修补这些版本或创建分支。 由于此限制，平台支持不支持依赖于 Kubernetes 上游的任何内容。

下表概述了与平台支持相比的社区支持的支持指南。

你可以使用一个相对于 kube-apiserver 版本较旧或较新的 kubectl 次要版本，这符合 kubectl 的 Kubernetes 支持策略。

例如，如果你的 kube-apiserver 为版本 1.28，你可以将版本 1.27 到 1.29 的 与该 kube-apiserver 结合使用。kubectl

若要安装 kubectl 或将它更新到最新版本，请运行：

az aks install-cli

Install-AzAksKubectl -Version latest

AKS 提供一年的“社区支持”和一年的“长期支持 (LTS)”，用于支持公共存储库上游社区提供的端口安全修补程序。 我们的上游 LTS 工作组为社区付出努力，为我们的客户提供更长的支持窗口。

有关 LTS 的详细信息，请参阅 对 Azure Kubernetes 服务（AKS）的长期支持。

你可以在 AKS Kubernetes 发布日历上参考即将推出的版本发布和弃用事项。

对于 Kubernetes 的新次要版本：

• AKS 将在删除前至少 30 天宣布新版本的计划发布日期和弃用 AKS 发行说明中的旧版本。
• 如果新版本可能会因 API 的弃用而在群集中引发问题，AKS 将使用 Azure 顾问发出警报。 此外，Azure 顾问还会在你无法再获得支持时发出警报
• AKS 会向具有 AKS 和门户访问权限的所有用户发布一个服务运行状况通知，并向订阅管理员发送一封电子邮件，其中包含计划的版本删除日期。

• 自版本移除起，你有 30 天的时间升级到受支持的次要版本，以继续获得支持。

对于 Kubernetes 的新修补程序版本：

• 由于修补程序版本的紧急性质，可以在修补程序变为可用时将其引入到服务中。 修补程序在发布后将会拥有最短两个月的生命周期。
• 通常情况下，对于新修补程序版本的发布，AKS 不会进行广泛地宣传。 但是，AKS 会持续监视和验证可用的 CVE 修补程序，以便及时在 AKS 中支持它们。 如果发现重要补丁或者需要用户进行操作，AKS 会通知你升级到新发布的补丁。
• 自从 AKS 中移除某个修补程序版本之日起，你有 30 天的时间升级到受支持的修补程序并继续获得支持。 但是，一旦弃用/删除该版本，就再也无法创建群集或节点池。

AKS 保留无需提前通知即可添加或删除具有一个或多个影响生产的关键 bug 或安全问题的新/现有版本的权利。

特定的修补程序版本可能会跳过发布或者加速推出，具体取决于 bug 或安全问题的严重性。

如果使用 Azure 门户、Azure CLI、Azure PowerShell 部署 AKS 群集，则群集默认为 N-1 次要版本和最新修补程序。 例如，如果 AKS 支持 1.29.2、1.29.1、1.28.7、1.28.6、1.27.11 和 1.27.10，则选择的默认版本为 1.28.7。

az aks get-versions --location chinaeast2 --output table

Get-AzAksVersion -Location chinaeast2

AKS 团队在 GitHub 上的文档中宣布新的 Kubernetes 版本发布日期，并通过电子邮件发送给即将结束支持的群集的订阅管理员。 此外，AKS 还会在你无法获得支持时使用 Azure 顾问在 Azure 门户内向你发出警报，并向你说明可能会影响你的应用程序或开发过程的已弃用的 API。

从 Kubernetes 1.19 开始，开放源代码社区将支持扩展到一年。 AKS 承诺启用修补程序并提供与上游承诺使用量匹配的支持。 对于版本 1.19 和更高版本上的 AKS 群集，你将能够每年至少升级一次，以便始终使用受支持的版本。

当升级的 Kubernetes 群集具有不受支持的次要版本时，会发生什么情况？

如果你使用的是 n-3 版本或更早版本，则意味着你不受支持，需要升级。 如果从版本 n-3 升级到 n-2 成功，你将回到我们的支持策略中。 例如：

• 如果支持的最低 AKS 次要版本为 1.27，而你使用的是 1.26 或更低版本，则你无法获得支持。
• 如果已成功从 1.26 升级到 1.27 或更高版本，请返回到我们的支持策略中。

不支持降级。

“不受支持”意味着：

• 正在运行的版本不在受支持的版本列表中。
• 当你请求支持时，系统将要求你将群集升级到受支持的版本，除非你正处于版本弃用后的 30 天宽限期内。

此外，对于受支持版本列表以外的群集，AKS 不会在正常运行时间或其他方面做出任何保证。

对于 AKS 不支持的次要版本，缩减或扩展可继续进行。 由于没有服务质量保证，因此我们建议升级，使群集重新可接受支持。

如果群集不支持三个以上的次要版本并带来安全风险，Azure 将主动联系你。 他们会建议您升级您的群集。 如果你不采取进一步的措施，Azure 将保留代表你自动升级群集的权利。

对于 AKS 不支持的次要版本，缩减或扩展可继续进行。 由于没有服务质量保证，因此我们建议升级，使群集重新可接受支持。

控制平面必须位于所有节点池的版本窗口中。 有关升级控制平面或节点池的详细信息，请访问有关升级节点池的文档。

版本偏差策略现在允许控制平面和代理池之间的版本差最多为 3 个版本。 AKS 从版本 1.28 开始遵循此偏差版本策略更改。

如果升级受支持的 AKS 群集，则无法跳过 Kubernetes 次要版本。 Kubernetes 控制平面版本倾斜策略不支持跳过次要版本。 例如，对于以下升级过程：

• 1.28.x -1.29.x：允许。>
• 1.27.x -1.28.x：允许。>
• 1.27.x -1.29.x：允许。>

对于控制平面版本升级，可以按顺序升级社区支持版本的 3 个次要版本。

若要从 1.27.x -1.29.x 升级，请执行以下操作：>

1. 从 1.27.x -1.28.x 升级。>
2. 从 1.28.x -1.29.x 升级。>

请注意，从 1.28 版本开始，根据版本倾斜策略，代理池版本最多可以比控制平面版本早 3 个版本。 如果您的版本远远落后于支持的最低版本，则可能需要执行多个控制平面升级操作才能达到支持的最低版本。 例如，如果你当前控制平面版本为 1.23.x，并且你打算升级到最低支持的 1.27.x 版本。 你可能需要从 1.23.x 按顺序升级 4 次才能达到 1.27.x。 另请注意，可以将代理池版本升级到控制平面次要版本。 在上面的示例中，当控制平面版本为 1.25.x 时，可以将代理池版本升级两次，即从 1.23.x 升级到 1.25.x。 随后，当控制平面版本为 1.27.x 时，从 1.25.x 升级到 1.27.x。 在就地升级（即控制平面和代理池一起升级）时，适用于控制平面升级的相同规则适用。

如果从 不受支持的版本 执行升级 ，则执行升级时无需任何功能保证，并被排除在服务级别协议和有限保证之外。 运行不受支持的版本的群集具有将控制平面升级与节点池升级分离的灵活性。 但是，如果版本过期，建议重新创建群集。

否，在平台支持期间无法创建新群集。

可以，只要它们与控制平面版本兼容，就可以添加代理池。

有关如何升级群集的信息，请参阅：

• 升级 Azure Kubernetes 服务 (AKS) 群集
• 通过 Azure Kubernetes 舰队管理器升级多个 AKS 群集