Compartir a través de

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

  • Artículo

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

AKS 支持在此“社区支持”窗口中的 Kubernetes 版本，以从社区版本推送 bug 修复和安全更新。 虽然社区支持的发布节奏提供了好处，但它要求你随时了解 Kubernetes 的版本，这可能会很困难，具体取决于你的应用程序的依赖项和 Kubernetes 生态系统的变化速度。

为了帮助你管理 Kubernetes 版本升级，AKS 提供了长期支持 (LTS) 选项，该选项延长了 Kubernetes 版本的支持窗口，让你有更多的时间来规划和测试向较新的 Kubernetes 版本的升级。

AKS 支持类型

大约一年后，给定的 Kubernetes 次要版本将退出社区支持，使 bug 修复和安全更新对你的 AKS 群集不可用。

AKS 提供一年的社区支持和一年的长期支持，以支持公共 AKS 存储库上游的社区提供的端口安全修复。 上游 LTS 工作组努力回馈社区，为客户提供更长的支持窗口。 LTS 旨在为你提供更长的时间对升级进行规划和测试，从指定的 Kubernetes 版本正式发布 (GA) 起提供两年的时间。

社区支持 长期支持
何时使用 当你可以及时掌握上游 Kubernetes 版本的信息时 当你需要控制何时从一个版本迁移到另一个版本时
支持版本 三个 GA 次要版本 一个 Kubernetes 版本（当前为 1.27版本），为期两年

启用长期支持

启用 LTS 需要将群集移动到高级层，并显式选择 LTS 支持计划。 尽管群集处于*社区支持中时可以启用 LTS，但系统会在你启用高级层后向你收费。

在新群集上启用 LTS

  • 使用 az aks create 命令创建启用了 LTS 的新群集。

    作为示例，以下命令使用 Kubernetes 版本 1.27 创建启用了 LTS 的新 AKS 群集。 若要查看可用的 Kubernetes 版本，请参阅 AKS 发布跟踪器。

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --generate-ssh-keys

在现有群集上启用 LTS

  • 使用 az aks update 命令在现有群集上启用 LTS。

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport

迁移到最新的 LTS 版本

上游 Kubernetes 社区支持两个次要版本升级路径。 该过程会在升级过程中迁移 Kubernetes 群集中的对象，并提供经过测试和认可的迁移路径。

如果你想要执行就地迁移，AKS 服务会将控制平面从上一 LTS 版本迁移到最新版本，然后迁移数据平面。 若要对最新的 LTS 版本进行就地升级，需要将启用了 LTS 的 Kubernetes 版本指定为升级目标。

  • 使用 az aks upgrade 命令迁移到最新的 LTS 版本。

    以下命令使用 Kubernetes 版本 1.32.2 作为示例版本。 若要查看可用的 Kubernetes 版本，请参阅 AKS 发布跟踪器。

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.32.2

    注意

    1.30 是 LTS 1.27 之后的下一个版本。 可以通过上述步骤从 1.30 版本群集选择加入 LTS。 LTS 版本 1.27 将于 2025 年 7 月结束生命周期 (EOL)。

在现有群集上禁用长期支持

在现有群集上禁用 LTS 需要将群集移动到免费层或标准层，并显式选择 KubernetesOfficial 支持计划。

一个 LTS 版本和下一个版本之间大约有两年时间。 除了对迁移两个以上次要版本的上游支持外，应用程序很可能依赖于已弃用的 Kubernetes API。 建议在目标 LTS Kubernetes 版本上全面测试应用程序，并执行从一个版本到另一个版本的蓝/绿部署。

  1. 使用 az aks update 命令在现有群集上禁用 LTS。

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier [free|standard] --k8s-support-plan KubernetesOfficial

  2. 使用 az aks upgrade 命令将群集升级到更高的受支持版本。

    以下命令使用 Kubernetes 版本 1.28.3 作为示例版本。 若要查看可用的 Kubernetes 版本，请参阅 AKS 发布跟踪器。

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.28.3

不支持的加载项和功能

AKS 团队当前跟踪存在 Kubernetes 社区支持的附加产品版本。 版本离开社区支持后，我们将依赖托管加载项的开放源代码项目来延续该支持。 由于各种外部因素，某些加载项和功能可能不支持这些上游社区支持窗口之外的 Kubernetes 版本。

下表提供了不受支持的加载项和功能的列表及其不受支持的原因：

附加产品/功能 不支持的原因
Istio Istio 支持周期较短（6 个月），Kubernetes 1.27 将不会有维护版本。
Keda 无法保证与 Kubernetes 1.27 的未来版本兼容性。
Calico 要求 Calico Enterprise 协议超出社区支持。
密钥管理服务 (KMS) KMSv2 在此 LTS 周期中替换 KMS。
Dapr 不支持 AKS 扩展。
应用程序网关入口控制器 在 LTS 期间迁移到适用于容器的应用程序网关。
Open Service Mesh OSM 已弃用。
AAD Pod 标识 “已弃用”取代工作负载标识。

注意

如果启用了这些附加产品或功能中的任何一项，则无法将群集移动到长期支持。

尽管 Microsoft 不支持这些 AKS 托管加载项，但如果你想要在社区支持过后使用它们，则可以在群集上安装它们的开源版本。

如何确定下一个 LTS 版本

Kubernetes LTS 的版本从正式分布起两年内可用，我们根据以下条件将 Kubernetes 的一个较高版本标记为 LTS：

  • 为客户提供的从之前的 LTS 版本迁移到当前 LTS 版本的充足时间已过。
  • 上一版本有两年的支持窗口。

请阅读 AKS 发行说明，了解你何时能够规划迁移。

常见问题解答

对 AKS 1.27 的社区支持将于 2024 年 7 月到期。 是否可以在该日期之后使用 1.27 版本创建新 AKS 群集？

可以，只要在群集上启用了 LTS，就可以在社区支持窗口结束后使用 1.27 版本创建新 AKS 群集。

在社区支持终止后，是否可以在 AKS 1.27 上启用和禁用 LTS？

可以在社区支持终止后在 AKS 1.27 上启用 LTS 支持计划。 但是，在社区支持终止后，无法在 AKS 1.27 上禁用 LTS。

我有一个在 1.27 版本上运行的群集。 这是否意味着它会自动启用 LTS？

否，您需要显式地在群集上启用 LTS 才能获得 LTS 支持。 启用 LTS 还需要在高级层上进行。

什么是 LTS 定价模型？

LTS 在高级层上可用，有关详细信息，请参阅高级层定价。

启用 LTS 后，群集的 autoUpgradeChannel 已更改为修补通道

这是正常情况。 如果没有为 AKS 群集定义 autoUpgradeChannel，则它默认使用 LTS 进行 patch。