Azure Operator Nexus Kubernetes 服务中支持的 Kubernetes 版本

本文档概述了用于 Operator Nexus Kubernetes 服务的版本控制架构，其中包括支持的 Kubernetes 版本。 它解释了主要版本、次要版本和修补程序版本之间的差异，并提供有关升级 Kubernetes 版本以及升级体验预期的内容的指导。 它还涵盖版本支持生命周期，包括对每个版本捆绑包的支持终止。 以前称为加载项的功能是每个版本捆绑包中包含的软件组件。 组件版本和中断性变更 阐明了版本捆绑包中包含的功能版本。 有关功能的详细信息，请参阅 Nexus Kubernetes 群集功能。

Kubernetes 社区大约会每隔三个月发布次要版本。 从版本 1.19 开始，Kubernetes 社区 将每个版本的支持窗口从 9 个月增加到一年。

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

Kubernetes 版本

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

[major].[minor].[patch]

Examples:
 1.24.7
 1.25.4

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

• 当可能引入 API 的中断性变更时，主要版本号会发生变化
• 当功能更新与其他次要版本后向兼容时，“次要版本号”会发生变化。
• 进行后向兼容的 bug 修复时，“补丁版本号”会发生变化。

强烈建议你及时了解最新推出的补丁。 例如，如果生产群集基于 1.25.4，则 1.25.6 是最新推出的适用于 1.25 系列的补丁版本。 应尽快升级到 1.25.6 以确保群集得到完全修补并受支持。 若要更详细地了解如何升级群集，可参阅升级 Kubernetes 版本文档。

Nexus Kubernetes 发布日历

在 Nexus Kubernetes 发布日历上查看即将发布的版本。

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

Nexus Kubernetes 服务版本组件

Operator Nexus Kubernetes 服务版本由两个离散组件组成，这些组件组合成单个表示形式：

• Kubernetes 版本。 例如，1.25.4 是在 Operator Nexus 中部署的 Kubernetes 版本。 这些包由 Azure AKS 提供，其中包括 Operator Nexus 支持的所有补丁版本。 有关 Azure AKS 版本的详细信息，请参阅 AKS 支持的 Kubernetes 版本
• 一个版本号，用于将操作员 Nexus Kubernetes 群集中的节点使用的 Kubernetes 版本、功能和作系统 （OS） 映像封装为单个数字。 例如 2.†

这些值的组合在 API 中表示为单个 kubernetesVersion。 例如， 1.25.4-2 或者支持的 v 表示法： v1.25.4-2。

†截至 2025 年 4 月版本捆绑包的增量已更改为包括发布版本控制，而不是按顺序编号，以一目了然地提供发布到发布的独特性。 继续阅读有关此更改的详细信息。

版本捆绑包

版本捆绑包是添加到 Kubernetes 版本的辅助值。 版本捆绑包适用于 Kubernetes 版本不变的情况，但作系统和/或功能随 Nexus 版本更新。 此类更新可能包括但不限于：更新的作系统映像、功能修补程序版本以及引入新的平台功能。

在 2025 年 4 月之前，版本捆绑编号从 Nexus 开始 1 递增，并因特定 Kubernetes 修补程序版本在 Nexus 上可用的时间而异。 2025 年 4 月之后，同一版本中的所有版本捆绑包都以相同的发布标识符编号，例如 -4.4.0 或 -4.5.0。 图表详细说明了哪些版本捆绑包属于同一系列。

版本捆绑包使用户能够规划和管理操作员 Nexus Kubernetes 服务提供的 Kubernetes 群集升级过程。

所有 Nexus 群集升级都遵循标准 Kubernetes 版本倾斜策略。 在某些情况下，可能需要多个升级才能将群集引入所需的 Kubernetes 版本。 已接受跳过任何版本捆绑包版本，但无法降级到以前的版本捆绑包系列。

对已部署 Operator Nexus Kubernetes 群集的配置的更改只应在 Kubernetes 次要版本升级期间应用，而不应在补丁版本升级期间应用。 在次要版本升级期间可以应用的配置更改示例包括：

• 将 kube-proxy 的配置从使用 iptable 更改为 ipvs。
• 将容器网络接口（CNI）从一个产品更改为另一个产品。

为升级方案选择版本捆绑包

我们允许从一个 Kubernetes 次要版本中的任何修补程序版本升级到下一个 Kubernetes 次要版本中的任何修补程序版本，从而提供灵活性。 即使存在中间版本 1.31.2-x.x.x，也允许从 1.31.1-x.x.x 升级到 1.32.x-x.x.x。

发布新版本捆绑包后，该版本捆绑包中的所有 Kubernetes 修补程序版本都使用相同的作系统和功能版本;只有 Kubernetes 代码在两者之间不同。 让我们看看一些可能需要的升级路由示例：

Kubernetes 版本更新

若要修补或更新 Kubernetes 次要版本，请从同一版本捆绑包系列中选择可用的 Kubernetes 版本。 例如，如果 1.32.1-4.4.0 是当前版本捆绑包，并且 1.33.1-4.4.0 是最新的 1.33.x 版本捆绑包，则应选择 1.33.1-4.4.0。

OS 和组件版本更新

若要在维护同一 Kubernetes 版本的同时修补或更新 OS 或平台组件，请在与群集相同的 Kubernetes 次要版本中选择版本捆绑包，但具有更高版本的版本号。 例如，如果 1.32.1-4.4.0 是当前版本捆绑包，而 1.32.1-4.5.0 是最新的 1.32.1 版本捆绑包，则选择 1.32.1-4.5.0 捆绑包。

Kubernetes、OS 和组件版本更新

若要同时修补或更新 Kubernetes 版本、OS 版本和平台组件，请选择后续 Kubernetes 次要版本的最新版本。 例如，如果 1.32.1-4.4.0 是当前版本捆绑包，后续 Kubernetes 次要版本的最新版本捆绑包为 1.33.2-4.5.0，则选择 1.33.2-4.5.0 升级所有组件。

在前两种情况下，如果未发布包含所需升级的版本捆绑包，可能需要接受更新的 Kubernetes 版本或组件版本。 在这种情况下，任何后续 Kubernetes 次要版本都有效，但具有最新版本的版本捆绑包是该 Kubernetes 次要版本的最 up-to日期和安全版本。 建议为给定版本捆绑包选择最新版本。

组件版本和中断性变更

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

• azure-arc-k8sagents 版本是指随版本捆绑包随附的此功能版本。 已启用 Arc 的 Kubernetes 代理设置为随时自动升级到最新版本的代理。
• 从 4.6.0 开始，ipam-cni-plugin 版本反映了内部应用版本（4.6.0-32）与图表版本（1.0.10）。 对于 4.6.0，这两者都是为了转换而显示的。

版本捆绑功能

升级 Kubernetes 版本

若要详细了解如何升级群集，请参阅升级 Azure Operator Nexus Kubernetes 服务群集。

Kubernetes 版本支持策略

Operator Nexus 支持三个 Kubernetes 次要版本：

• Operator Nexus 中发布的最新 GA 次要版本（我们将其称为 N）。
• 以前的两个次要版本。
• 每个受支持的次要版本还支持最多两个最新的稳定补丁，而以前的补丁在次要版本的生存期内均受延长可用性策略约束。

Operator Nexus Kubernetes 服务为发布的每个 Kubernetes 次要版本提供标准化的支持期限。 版本遵循两条不同的时间线，反映：

• 支持持续时间 - 版本的积极维护时间是多长。 在支持的时间段结束时，将考虑 End of Support该版本。
• 扩展可用性 – 以后可以选择版本进行部署 End of Support的时间。

操作员 Nexus 上 Kubernetes 版本的受支持窗口称为 N-2：（N（最新版本）-2（次要版本），代表 .letter 修补程序版本。

例如，如果 Operator Nexus 当前引入了 1.17.a，则提供以下版本的支持：

引入新的次要版本后，受支持的最早次要版本和补丁版本不再受支持。 例如，当前支持的版本列表为：

1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f

Operator Nexus 发布 1.18.* 后，所有 1.15.* 版本不再受支持。

支持时间线

Operator Nexus Kubernetes 服务通常提供 12 个月的支持，从次要版本的初始 AKS GA 版本开始算。 此时间线遵循 Azure AKS 的时间安排，其中包括声明的长期支持版本 1.27。

支持的版本：

• 可以作为新的 Operator Nexus Kubernetes 群集进行部署。
• 可以作为从先前版本进行的升级的目标。 受到正常升级路径的限制。
• 次要版本中可能有额外的补丁或版本捆绑包。

终止支持

End of Support 表示不再生成修补程序或版本捆绑包。 无法升级群集，因为最新的支持版本不再可用。 在这种情况下，升级的唯一方法是使用受支持的更新版本完全重新创建 Nexus Kubernetes 群集。 可以利用通过 Extended availability 进行的不受支持的升级来返回到受支持的版本。

延长可用性策略

在不支持的 Kubernetes 版本的延长可用性期间，用户不会收到安全修补程序或 bug 修复。 有关支持类别的详细信息，请参阅下表。

已放弃的 Nexus Kubernetes 群集

在延长可用性期结束后，K8s 版本将从 Nexus 中删除。 此时，任何基于此 K8s 版本的现有 Nexus Kubernetes 群集都将被放弃。 被遗弃的群集唯一支持的操作是删除。 重要的是，一旦放弃群集，就不可能升级到更高版本的 K8s。

支持的 kubectl 版本

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

例如，如果你的 kube-apiserver 在 1.17，则可以将版本 1.16 到 1.18 的 kubectl 与该 kube-apiserver 结合使用。

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

az aks install-cli

Install-AzAksKubectl -Version latest

长期支持 (LTS)

Kubernetes 社区大约每四个月发布一个新的次要版本，每个版本的支持窗口为一年。 在 Azure Kubernetes 服务 (AKS) 中，这一支持称为“社区支持”。

AKS 支持在此“社区支持”窗口中的 Kubernetes 版本，以从社区版本推送 bug 修复和安全更新。

通过此版本提供的创新节奏提供了最新的 Kubernetes 功能和最新的安全性。 但是，根据必须维护的群集数，保持最新状态可能很困难。

支持类型

大约一年后，Kubernetes 版本会退出社区支持，AKS 群集现在面临风险，因为 bug 修复和安全更新变得不可用。

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

LTS 提供从 Kubernetes 版本的正式版开始的两年内规划和测试升级的较长时间。

从 LTS 迁移到下一个 LTS 版本

Nexus Kubernetes 群集不支持 LTS 版本之间的直接升级。 若要从一个 LTS 版本过渡到下一个 LTS 版本，有两个选项：

• 使用所需的 LTS 版本创建新群集，并将工作负载移动到此新群集。
• 在到达下一个 LTS 版本之前，通过受支持的版本执行一系列中间升级。

FAQ

Microsoft 如何通知我关于新 Kubernetes 版本的发布？

本文档会定期更新新 Kubernetes 版本的计划日期。

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

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

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

如果你使用的是 N-3 版本或更低版本，则你不在支持范围内。 从版本 N-3 升级到 N-2 后，你就可以再次获得我们的支持。 例如：

• 如果支持的最低 AKS 版本为 1.25.x，而你使用的版本为 1.24.x 或更低，则你无法获得支持。
• 成功地从 1.24.x 升级到 1.25.x 或更高版本后，你就可以再次获得我们的支持。
• 不支持“跳级式升级”。 若要从 1.23.x 升级到 1.25.x，必须先升级到 1.24.x，然后再升级到 1.25.x。

不支持降级。

如果不升级集群，会发生什么？

如果不升级群集，你会继续获得所运行的 Kubernetes 版本的支持，直到支持期结束。 此后，你将不再获得群集支持。 你需要将群集升级到受支持的版本才能继续获得支持。

如果我没有在延长可用性期结束之前升级群集，会发生什么情况？

如果在延长可用性期结束时未升级群集，则无法再将群集升级到受支持的版本或横向扩展代理池。 你需要使用受支持的版本重新创建群集才能继续获得支持。

“不受支持”是什么意思？

“不受支持”意味着：

• 正在运行的版本不在受支持的版本列表中。
• 当你请求支持时，系统会要求你将群集升级到受支持的版本。

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

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

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

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

升级受支持的 Operator Nexus Kubernetes 群集时，不能跳过 Kubernetes 次要版本。 Kubernetes 控制平面版本倾斜策略不支持跳过次要版本。 例如，对于以下升级过程：

• 1.12.x ->1.13.x：允许。
• 1.13.x ->1.14.x：允许。
• 1.12.x ->1.14.x：不允许。

若要实现 1.12.x 到 1.14.x 的升级，需要逐步执行以下升级>：

1. 从 1.12.x 升级到 1.13.x。
2. 从 1.13.x 升级到 1.14.x。

是否可以在延长可用性期间创建新群集？

是的，你可以在延长可用性期间创建新的 1.xx.x 群集。 但是，我们建议你使用最新的受支持版本创建新群集。

是否可以在延长可用性期间将群集升级到更新的版本？

是的，你可以在延长可用性期间将 N-3 群集升级到 N-2。 如果群集当前在 N-4 上，则可以利用扩展的可用性，首先从 N-4 升级到 N-3。 N-3 升级完成后，继续升级到受支持的版本（N-2）。

我在扩展可用性窗口中，是否可以仍添加新节点池，或者必须升级吗？

是的，你可以将节点池添加到群集中。