通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

支持 Azure Red Hat OpenShift 4 的生命周期

  • 项目

Red Hat 大约每四个月发布一次 Red Hat OpenShift 容器平台 (OCP) 的次要版本。 这些版本包括新增功能和改进。 补丁发布频率更高（通常每周一次），可能包括对安全漏洞或 bug 的修复。

Azure Red Hat OpenShift 是通过 OCP 的特定发布进行构建。 本文介绍了 Azure Red Hat OpenShift 支持的 OCP 版本以及有关更新、弃用和支持策略的详细信息。

Red Hat OpenShift 版本

Red Hat OpenShift 容器平台使用语义化版本控制。 语义化版本控制使用不同级别的版本号指定不同的版本。 下表说明了语义版本号的不同部分，在此例中使用示例版本号 4.15.16。

主版本 (x) 次要版本 (y) 补丁版本 (z)
4 15 16
  • 主版本：目前没有计划发布主版本。 主要版本涉及核心服务的重大变化，例如大规模增加新特性和功能、体系结构更改、删除现有功能。
  • 次要版本：大约每四个月发布一次。 次要版本更新可能包括新添功能、增强功能、弃用、删除、bug 修复、安全增强以及其他改进。
  • 补丁版本：通常每周发布一次，或根据需要发布。 补丁版本更新可能包括 bug 修复、安全增强以及其他改进。

你的目标应是运行自己运行的主要版本的最新次要版本。 例如，如果生产群集使用版本 4.14，而 4.15 是 4 系列的最新正式发布次要版本，则应尽快更新到 4.15。

更新频道

更新通道是用户声明要将其群集更新到的 OpenShift 容器平台次要版本的机制。 更新通道与 Red Hat OpenShift 容器平台的次要版本关联。 通道中的版本号代表群集最终将更新到的目标次要版本。 更新通道不建议更新到高于所选通道版本的版本。 例如，OCP stable-4.14 更新通道不包含对 4.15 版本的更新。 更新通道仅控制版本选择，不会修改群集的当前版本。 有关详细信息，请参阅了解更新通道和版本。

重要

Azure Red Hat OpenShift 仅提供对稳定通道的支持。 例如：stable-4.15。

可以使用 stable-4.15 通道从以前的 Azure Red Hat OpenShift 次要版本更新。 已使用 fast 或 candidate 通道进行更新的群集可能会使你的群集处于“有限支持”状态。

Azure Red Hat OpenShift 版本支持策略

Azure Red Hat OpenShift 版本可用性

可通过以下两种机制之一获得 Azure Red Hat OpenShift 版本：

  • 当现有群集有较新版本的更新可用时
  • 当新版本可用作新群集的安装目标时

更新可用性

Azure Red Hat OpenShift 支持 Red Hat OpenShift 容器平台的正式发布 (GA) 次要版本，前提是 OpenShift stable 通道中有可用更新。 可以在 Red Hat OpenShift 容器平台更新图页面中检查更新可用性。

安装可用性

可以通过使用 Azure Red Hat OpenShift 发布日历或通过运行以下 Azure CLI 命令来验证可安装版本：

az aro get-versions --location [region]

版本生命周期结束

可以在 Azure Red Hat OpenShift 发布日历中找到 Azure Red Hat OpenShift 版本的生命周期结束日期。

注意

如果你在运行不受支持的 Red Hat OpenShift 版本，则当你请求对群集的支持时，系统可能会要求你进行更新。 运行不受支持的 Red Hat OpenShift 版本的群集不在 Azure Red Hat OpenShift SLA 涵盖范围内。

必需更新

在极端情况下，根据对 CVE 对环境的重要性的评估，Azure Red Hat OpenShift 站点可靠性工程师 (SRE) 可能会自动将关键补丁更新应用于群集，然后向你发送通知，告知你有关更改。 最佳做法是，在补丁 (z-stream) 更新可用时立即安装这些更新。

“有限支持”状态

当群集转换为“有限支持”状态（也称为“不在支持范围内”）时，Azure Red Hat OpenShift SRE 不再主动监视群集。 此外，SLA 不再适用，根据 SLA 请求的额度会被拒绝，但这并不意味着你不再获得产品支持。

群集可能因多种原因而转换为“有限支持”状态，这些原因包括以下情况：

  • 如果你未在版本生命周期结束日期之前将群集更新到受支持的版本。

    • 对于生命周期结束日期之后的版本，不再提供运行时保证或 SLA 保证。 为了避免这种情况，并且为了继续获得全面支持，请在生命周期结束日期之前将群集更新到受支持的版本。 如果你未在版本生命周期结束日期之前更新群集，则群集将转换为“有限支持”状态，直到更新到受支持的版本为止。
    • Azure Red Hat OpenShift SRE 提供商业上合理的支持，目的是让用户从不受支持的版本更新到受支持的版本。 但是，如果受支持的更新路径不再可用，你可能必须创建一个新的群集并迁移工作负荷。

  • 如果删除或替换任何原生 Azure Red Hat OpenShift 组件或由服务安装和管理的任何其他组件。

    • 如果使用了管理员权限，则 Azure Red Hat OpenShift 不对你或你的授权用户的任何操作负责，其中包括影响基础结构服务或服务可用性的操作或者导致数据丢失的操作。 如果检测到任何此类操作，则群集可能会转换为“有限支持”状态。 然后，你应该还原操作或创建支持案例来探索修正步骤。
    • 在某些情况下，如果修正了违规因素，群集可以恢复到完全受支持的状态。 但是，在其他情况下，可能必须删除并重新创建群集。
    • 有关群集配置要求的详细信息，请参阅 Azure Red Hat OpenShift 支持策略。

支持的版本策略例外情况

Azure Red Hat OpenShift SRE 团队保留相关权利来添加或删除新的/现有版本，或是延迟被确定为具有一个或多个关键生产影响 bug 或安全问题且未提前通知的即将推出次要发布版本。

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

Azure Red Hat OpenShift 发布日历

请参阅以下指南以了解过去的 Red Hat OpenShift 容器平台（上游）发布历史记录。

OCP 版本 OCP GA 可用性 ARO 安装可用性 ARO 生命周期结束
4.4 2020 年 5 月 2020 年 7 月 2021 年 2 月
4.5 2020 年 7 月 2020 年 11 月 2021 年 7 月 15 日
4.6 2020 年 10 月 2021 年 2 月 2021 年 9 月 15 日
4.7 2021 年 2 月 2021 年 7 月 15 日 2022 年 2 月 1 日
4.8 2021 年 7 月 2021 年 9 月 15 日 2022 年 6 月 21 日
4.9 2021 年 11 月 2022 年 2 月 1 日 2023 年 3 月 2 日
4.10 2022 年 3 月 2022 年 6 月 21 日 2023 年 8 月 19 日
4.11 2022 年 8 月 2023 年 3 月 2 日 2024 年 2 月 10 日
4.12 2023 年 1 月 2023 年 8 月 19 日 2024 年 10 月 17 日
4.13 2023 年 5 月 2023 年 12 月 15 日 2024 年 11 月 17 日
4.14 2023 年 10 月 2024 年 4 月 25 日 2025 年 5 月 1 日
4.15 2024 年 2 月 即将推出 2025 年 6 月 27 日

常见问题解答

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

Azure Red Hat OpenShift 支持安装与上表中的日期一致的次要版本。 只要稳定通道中存在某个版本的更新路径，就会支持该版本。 如果运行的版本已超过生命周期结束日期，你将无法获得支持，系统可能会要求你进行更新以继续获得支持。 从旧版本更新到受支持的版本可能会很困难，有些情况下甚至不可能。 建议将群集保留在最新的 OpenShift 版本上，以避免潜在的更新问题。

例如，如果最早的受支持 Azure Red Hat OpenShift 版本为 4.13，而使用的是 4.12 或更低版本，则无法获得支持。 从 4.12 更新到 4.13 或更高后续版本之后，你会被重新涵盖在我们的支持策略中。

不支持将群集还原到以前的版本或进行回滚。 仅支持更新到较新版本。

“无法获得支持”或“有限支持”是什么意思？

如果 ARO 群集运行的 OpenShift 版本不在受支持的版本列表中，或者正在使用不受支持的群集配置，则表明群集“不受支持”。 因此：

  • 为群集创建支持工单时，系统可能会要求你将群集更新到受支持的版本，然后你才能获得支持。
  • 不受支持的群集的任何运行时或 SLA 保证都是无效的。
  • “不受支持”的群集只能按照“尽最大努力”的原则来修补。
  • 不会监视不受支持的群集。