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

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

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

Kubernetes 版本

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

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

版本中的每一个数字都反映了与以前版本的兼容性：

• 主要版本：引入不兼容的 API 更改或中断向后兼容性。
• 次要版本：在保持向后兼容性的同时添加新功能。
• 修补程序版本：包括向后兼容的错误修复。

始终对当前小版本使用最新的补丁版本。 例如，如果你的生产群集使用 1.29.1，而 1.29.2 是 1.29 次要版本可用的最新补丁版本，那么你应尽快升级到 ，确保你的群集得到全面的修补并受到支持。1.29.2

AKS Kubernetes 发布日历

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

有关过去的发布历史记录，请参阅 Kubernetes 历史记录。

LTS 版本

需要启用长期支持（LTS）才能获得扩展支持。 有关详细信息，请参阅 “启用长期支持”。

AKS Kubernetes 版本计划甘特图

以下甘特图显示当前版本：

AKS 组件重大变更（按版本）

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

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

别名的次要版本

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

若要查看当前的补丁，请运行 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",
}

Kubernetes 版本支持策略

AKS 将正式发布版 (GA) 定义为可在所有区域提供并在所有 SLO 或 SLA 衡量标准中启用的版本。 AKS 支持三个 Kubernetes GA 次要版本：

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

AKS 还可能支持预览版本，这些版本已显式标记并受 preview 条款和条件的约束。

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 版本提供的减少支持的计划。 在平台支持期间，客户只有在 AKS/Azure 平台相关问题上才能得到 Azure 的支持。 与 Kubernetes 功能和组件相关的任何问题不受支持。

平台支持策略适用于 N-3 版本中的群集（其中 N 是最新支持的 AKS GA 次要版本），然后群集将降至 N-4。 例如，当 v1.29 是最新的 GA 版本时，Kubernetes v1.26 被视为平台支持。 假设你运行的是 N-2 版本。 当版本变为N-3时，其官方支持也随之结束，然后您将进入平台支持政策。

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

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

支持的 kubectl 版本

可以使用 kubectl 比 kube-apiserver 版本更早或更新一个次要版本的版本。 有关详细信息，请参阅 kubectl 的 Kubernetes 支持策略。

例如，如果 kube-apiserver 为 1.28，则可以使用版本 1.27 到 1.29 的kubectl。

若要安装或更新 kubectl 到最新版本，请使用基于首选工具的命令：

az aks install-cli

Install-AzAksKubectl -Version latest

长期支持 (LTS)

AKS 提供一年社区支持和一年长期支持 (LTS)，包括从上游社区回溯移植的安全补丁。 我们的上游 LTS 工作组通过努力回馈社区，为我们的客户提供更长的支持周期。

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

发布和弃用流程

你可以在 AKS Kubernetes 发布日历上查看即将发布的版本和弃用情况。

对于 Kubernetes 的新次要版本：

• AKS 将在删除前至少 30 天在 AKS 发行说明 中宣布新版本发布日期和旧版本弃用。
• AKS 使用 Azure 顾问 提醒你，如果新版本可能会导致群集中因 API 已弃用而出现问题。 如果不受支持，Azure 顾问还会向你发出警报。
• AKS 发布了服务运行状况通知，可供拥有 AKS 和门户访问权限的所有用户使用，并向订阅管理员发送电子邮件，告知计划的版本移除日期。

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

对于 Kubernetes 的新补丁版本：

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

支持的版本策略例外情况

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

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

Azure 门户和命令行界面版本

如果使用 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。

若要了解订阅和区域当前可用的版本，请使用基于首选工具的命令：

# The following example lists the available Kubernetes versions for the chinaeast2 region:

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

# The following example lists the available Kubernetes versions for the chinaeast2 region:

Get-AzAksVersion -Location chinaeast2

常见问题 (FAQ)

Azure如何通知我新的 Kubernetes 版本？

AKS 团队通过我们的文档、GitHub，并通过电子邮件向支持即将结束的集群的订阅管理员宣布新的 Kubernetes 版本发布日期。 AKS 还通过 Azure 顾问 在 Azure 门户中向您发出警报，如果您的服务不再受支持，并通知您弃用的 API 可能会影响您的应用程序或开发过程。

我应该多久升级一次 Kubernetes 版本才能始终获得支持？

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

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

如果您使用的版本根据支持的 Kubernetes 版本列表已不再受支持，则需要升级。 你可以从不支持的版本升级到受支持的版本。 例如：

• 如果受支持的 AKS 次要版本最低为 1.33 ，并且你使用的是 1.32 或更高版本，则不受支持。
• 如果已成功从 1.32 升级到 1.33 或更高版本，则返回到支持策略中。

不支持降级或回滚到不支持的版本。 此外，集群版本离最低受支持版本越远，出现升级问题的可能性就越高。 在这种情况下，创建新的群集和工作负荷迁移将是一种更好的方法。

“不受支持”意味着什么？

“支持范围之外”表示：

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

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

是否可以永久保留 Kubernetes 版本？

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

如果使用不受支持的次要版本缩放 Kubernetes 群集，会发生什么情况？

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

如果节点池不在某个受支持的 AKS 版本中，控制平面支持哪个版本？

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

控制平面和节点池之间允许的版本差异是什么？

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

是否可以在群集升级期间跳过多个 AKS 版本？

可以，在某些情况下可以跳过次要版本。 但是，如果在不升级节点池的情况下单独升级控制平面，则必须遵循 Kubernetes 版本偏差策略。 Kubernetes 版本倾斜策略当前仅支持 N-3，因此控制平面和代理池必须彼此位于 N-3 内。

• LTS：启用了 AKS Long-Term 支持计划的版本。 请参阅 LTS 版本。
• 不支持的 LTS：LTS 支持 LTS 的版本在 LTS 版本 表中超过其 LTS 生命周期结束日期。
• 支持的非 LTS：不是 LTS 的版本，但仍在 AKS Kubernetes 发布日历中列为支持版本。
• 不支持的非 LTS：不是 LTS 的版本，不再在 AKS Kubernetes 发布日历中列为支持。

示例：

• 如果群集在 1.29 LTS 上，并且想要迁移到 1.32 LTS，则可以跳过多个次要版本，前提是 AKS 仍提供 1.32 LTS ，并且升级满足版本倾斜和验证检查。
• 如果您的群集位于1.28 非 LTS版本上，只要目标版本已由 AKS 列出、满足验证检查，并且您执行的是完整的群集升级而不是，就可以通过不受支持的恢复路径迁移到 AKS LTS control-plane-only。
• 如果群集位于受支持的非 LTS 1.33 上，并且想要迁移到受支持的非 LTS 1.35，则无法直接从 1.33 跳到 1.35。 必须一次升级一个次要版本，例如 1.33 到 1.34，然后将 1.34 升级到 1.35。

在上表中， Unsupported recovery path 指示以无法保证安全的方式执行升级路径，因此被视为不受支持。 AKS 允许升级继续，但不受支持，并可能面临风险。

若要选择正确的路径，请通过运行 az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>来检查可用目标。 查看上表，然后考虑升级与重新创建群集和迁移工作负荷的风险。

是否可以在平台支持窗口内创建新的 1.xx.x 群集？

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

我使用的是一个新近弃用且不再受平台支持的版本。 是否仍可以添加新节点池，或者是否应升级？

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

相关内容

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

• 更新Azure Kubernetes 服务 (AKS)群集
• 通过 Azure Kubernetes Fleet Manager 更新多个 AKS 群集