通过

AKS 中支持的 Kubernetes 版本

  • 项目

本文介绍由 Azure Arc 启用的 Azure Kubernetes 服务支持的 Kubernetes 版本。Kubernetes 社区大约每三个月发布一次次要版本。 最近，Kubernetes 社区 将每个版本的支持时段从 9 个月增加到 12 个月，从版本 1.19 开始。

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

Kubernetes 版本

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

[major].[minor].[patch]

Example:
  1.17.7
  1.17.8

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

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

应安装正在运行的次要版本的最新修补程序版本。 例如，如果生产群集使用版本 1.17.7。 1.17.8 是 1.17 系列的最新可用修补程序版本。 应尽快升级到 1.17.8 以确保群集得到完全修补并受支持。

Kubernetes 版本支持策略

AKS 将正式发布的 (GA) 版本定义为部署或更新 Arc 启用的 AKS 时可供下载的版本。AKS 支持 Kubernetes 的三个 GA 次要版本：

  • 为 AKS (发布的最新 GA 次要版本，我们称之为 N) 。
  • 以前的两个次要版本。 每个受支持的次要版本还支持最多两 (2) 个稳定的修补程序。

AKS 可能还支持预览版，这些版本被显式标记为此类版本。

注意

AKS 使用涉及逐步区域部署的安全部署做法。 这意味着新版本或新版本可能需要长达 10 个工作日才能在所有区域推出。

AKS 上的 Kubernetes 版本的受支持窗口称为“N-2”：(N (最新版本) -2 (次要版本))。

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

新的次要版本 支持的版本列表
1.17.a 1.17.a、1.17.b、1.16.c、1.16.d、1.15.e、1.15.f

其中，“.字母”代表修补程序版本。

引入新的次要版本后，支持的最早次要版本和修补程序版本将被弃用并删除。 例如，当前支持的版本列表为：

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

当 AKS 发布 1.18.*时，所有 1.15.* 版本都将被删除，并在 30 天内不再受支持。

注意

如果运行的 Kubernetes 版本不受支持，则请求群集支持时，系统会要求升级。 运行不受支持 Kubernetes 版本的群集未涵盖在 AKS 支持策略中。

除此策略外，AKS 最多支持给定次要版本的两个修补程序版本。 给定以下受支持的版本：

Current Supported Version List
------------------------------
1.17.8, 1.17.7, 1.16.10, 1.16.9

如果 AKS 版本为 1.17.9 和 1.16.11，则会弃用并删除最早的修补程序版本，并且支持的版本列表变为：

New Supported Version List
----------------------
1.17.*9*, 1.17.*8*, 1.16.*11*, 1.16.*10*

支持的 kubectl 版本

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

例如，如果 kube-apiserver 的版本为 1.17，则可以使用该 kube-apiserver 的 1.16 到 1.18 kubectl 版本。

若要安装或更新你版本的 kubectl，请运行 az AKS on Azure Stack HCI and Windows Server install-cli。

发布和弃用流程

对于 Kubernetes 的新次要版本：

  • 在删除前至少 30 天， AKS 会在 AKS 发行说明 中发布预告，其中包含新版本发布的计划日期和相应的旧版本弃用。
  • 自版本删除起，用户有 30 天的时间升级到受支持的次要版本发布，以继续获得支持。

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

  • 由于修补程序版本的紧急性质，可以在修补程序变为可用时将其引入到服务中。
  • 通常情况下，对于新修补程序版本的发布，AKS 不会进行广泛地宣传。 但是，AKS 会持续监视和验证可用的 CVE 修补程序，以便及时在 AKS 中支持它们。 如果找到关键修补程序或需要用户操作，AKS 会通知用户升级到新提供的修补程序。
  • 从 AKS 中删除修补程序版本后，用户有 30 天的时间升级到受支持的修补程序并继续获得支持。

支持的版本策略例外情况

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

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

常见问题解答

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

AKS 团队在 GitHub 上的文档中发布包含新 Kubernetes 版本计划日期的预公告。

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

从 Kubernetes 1.19 开始， 开源社区将支持范围扩大到一年。 AKS 承诺启用修补程序并提供与上游承诺使用量匹配的支持。 对于 1.19 及更高版本的 Kubernetes 群集，每年至少升级一次，以保持受支持的版本。

对于 1.18 或更低版本，支持时间仍为 9 个月，这要求你每 9 个月升级一次才能始终使用受支持的版本。 定期测试新版本，并准备升级到更新的版本，以便在 Kubernetes 中获取最新的稳定增强功能。

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

如果你使用的是 n-3 版本或更早版本，这意味着你不受支持，系统会要求你升级。 从版本 n-3 成功升级到 n-2 后，你将重新涵盖在我们的支持策略中。 例如：

  • 如果受支持的最早 Kubernetes 版本为 1.15.a，并且使用的是 1.14.b 或更早版本，则不受支持。
  • 从 1.14.b 成功升级到 1.15.a 或更高版本后，你将回到我们的支持策略范围内。

不支持降级。

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

“不受支持”表示：

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

此外，AKS 不会为受支持的版本列表之外的群集提供任何运行时 (或其他) 保证。

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

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

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

升级受支持的 AKS 群集时，不能跳过 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.10.x 升级到受支持的 1.15.x。

是否可以在其 30 天支持时段内创建新的 1.xx.x 群集？

不是。 版本弃用/删除后，将无法使用该版本创建群集。 随着更改的推出，你将看到旧版本从版本列表中删除。 此过程最多可能需要两周时间（按区域逐步）。

我使用新弃用的版本。 是否仍可以添加新的节点池？ 还是必须升级？

错误。 无法将已弃用版本的节点池添加到群集。 你可以添加新版本的节点池。 但是，这可能需要先更新控制平面。

后续步骤

有关如何升级群集的信息，请参阅 更新 AKS 群集的 Kubernetes 版本。