此生命周期页中仅包括与最新的 Red Hat OpenShift 主版本相关的内容。 如需了解与 OpenShift 3 以及其它老版本 OpenShift 相关的内容，请参阅非当前 OpenShift 版本的生命周期页中的内容。


Red Hat OpenShift Container Platform 生命周期政策

概述

红帽为 Red Hat OpenShift Container Platform (“OpenShift” 或 “OCP”) 提供了公开的生命周期信息，用户和合作伙伴可根据此信息有效规划、部署及支持自己的相关环境。 红帽发布这个生命周期的主要目的是尽可能提供产品的透明度。但当出现特殊情况时，红帽可能会对这些政策做例外处理。

Red Hat OpenShift Container platform v4 提供了一个基于时间明确划分的、分阶段的生命周期。在其中的任何时间点上都至少可以支持 4 个次版本。 与生命周期相关的时间段从次版本的发布之日开始，并提供不同级别的支持和维护。 红帽计划以 4 个月的节奏进行新版本的发布，从而为客户提供足够的时间进行规划。

在整个生命周期中，活跃的订阅用户都可以访问所有发布的勘误。

OCP v4 Life Cycle

生命周期阶段

完全支持

此阶段从次版本的 GA/发布之日开始，并在 6 个月后，或后续的次版本发布的 90 天后结束，以较晚者为准。

全面支持会根据公布的“覆盖范围”和“服务等级协议”提供。 同样，开发支持也会根据公布的覆盖范围和服务等级协议提供。

在完全支持阶段中，会发布级别为关键（Critical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序可能会包括在定期发布的更新中。 为了获得安全勘误公告和程序错误修复，客户应将其 OpenShift 环境升级到最新支持的微版本（4.x.z）。

维护支持

对于 OpenShift 4.12 版本和更新的版本
此阶段在相应的次版本的完全支持阶段结束开始，并在 GA 的18 个月后结束。

在维护支持阶段中，级别为关键或重要的安全公告（RHSA），以及级别为紧急和精选的高优先级程序错误修复公告（RHBA），一旦可用就会发布。 一般情况下，红帽不会在此阶段发布其他级别的程序错误修复公告和功能增强公告（RHEA）。

对于 OpenShift 4.7 到 4.11
此阶段在相应 GA 的全面支持阶段之后开始，持续 12 个月。 对于其完全支持阶段超过 6 个月的版本，维护支持阶段的时间将相应减少，从而使完全支持阶段和维护支持阶段的累计时间为 18 个月。

在维护支持阶段中，级别为关键或重要的安全公告（RHSA），以及级别为紧急和精选的高优先级程序错误修复公告（RHBA），一旦可用就会发布。 一般情况下，红帽不会在此阶段发布其他级别的程序错误修复公告和功能增强公告（RHEA）。

在维护支持阶段结束时，软件和文档将继续提供给客户。但是，除提供协助升级到受支持版本的支持外，不会再提供其他任何技术支持。 OpenShift 集群可以完全正常工作可能需要红帽提供的托管服务的支持，而这些服务无法保证对未维护的及不受支持的 OpenShift 版本的支持。

延长更新支持（EUS）

从 OpenShift Container Platform 4.8 开始，红帽将所有次版本号为偶数的次版本（如 4.8、4.10、4.12）作为延长更新支持 (EUS) 版本。

对于 EUS 版本，上述的完全支持和维护支持阶段中的相应条件同样用于决定每个阶段的开始和结束日期。 OpenShift Container Platform EUS 版本包括了在 EUS 版本之间更轻松地进行升级的功能，可以简化工作节点的升级过程，并可以通过规划 EUS 到 EUS OpenShift 版本的升级策略来减少重启节点的情况。

从 OpenShift Container Platform 4.12 开始，红帽还会在所有 EUS 版本中包括 6 个月的延长更新支持(EUS) 阶段。 EUS 阶段将遵循给定版本的维护阶段。

对于 Red Hat OpenShift 的订阅者，通过延长更新支持 (EUS) 阶段进行支持是一个可选的服务。 借助 EUS，红帽为一组预定义的 Red Hat OpenShift 次版本提供关键 (Critical) 和重要 (Important) 的安全更新，以及紧急级别的程序错误修复。 通过 EUS， 客户可以在 24 个月内持续使用同一次发行版本的 Red Hat OpenShift，从而为任务关键型应用程序提供稳定的生产环境。

EUS 在 x86-64 版本的 Red Hat OpenShift Kubernetes Engine, Red Hat OpenShift Container Platform, 和 Red Hat OpenShift Platform Plus Premium 订阅中提供。 它还可作为一个可选的附加服务在 x86-64 版本的 Red Hat OpenShift Kubernetes Engine、Red Hat OpenShift Container Platform 和 Red Hat OpenShift Platform Plus Standard 订阅中提供。 如果不确定您是否有 EUS 服务或它是否适用于您的环境，请联络您的红帽销售代表。

延长生命阶段

仅适用于 4.8 版本

在延长生命周期阶段，通过 OpenShift Container Platform 订阅可以继续在红帽客户门户网站中访问之前发布的内容以及其他内容，如文档及红帽知识库。

对于处于延长生周阶段的产品，红帽会提供有限的技术支持。 在此阶段，不会提供程序漏洞修复、安全修复、硬件启用（Hardware Enablement）或根本原因分析，同时只对现有安装提供支持。

红帽保留在延长生命阶段随时终止对 OpenShift Container Platform 某个特定版本提供支持的权利。

生命周期日期

有关 4.6 EUS 结束日期的更多信息，请参阅 脚注 [9] ，有关 EUS 的更多信息，请参阅 脚注 [10]。

附加组件和依赖组件

RHEL CoreOS

RHEL CoreOS 是 OpenShift 4 的一个组件，并遵循 OpenShift 生命周期进行维护。 每个 OpenShift 版本都包含相应的 RHEL CoreOS流。[8]

OpenShift 的层次组件

OpenShift Container Platform 提供了不同的运行时和应用程序架构（由红帽直接提供，或由我们的合作伙伴提供）。 由红帽、我们的合作伙伴或第三方供应商提供的所有层次内容或容器产品，均有自己的、独立于 OpenShift 的生命周期。 如需了解这些组件在您所运行的 OpenShift 上被测试、认证或支持的状态，请联系相关的组件提供厂商。

由红帽提供的组件信息包括在下表中：

软件类别 提供的工具/功能 生命周期及经过测试的配置
Red Hat Software Collections PHP、Perl、Python、Ruby、node.JS、Postgres、MySQL、MongoDB https://access.redhat.com/support/policy/updates/rhscl
JBoss Products Add-ons EAP、EWS/JWS、Fuse、AMQ、BRMS、Data Grid https://access.redhat.com/support/policy/updates/jboss_notes 和 https://access.redhat.com/articles/5115291

Red Hat OpenShift Data Foundation

（以前称为 Red Hat OpenShift Container Storage）

自 OpenShift 4.2 开始，OpenShift Container Storage (OCS) v4 作为一个可选的、可安装的组件。 OCS 由上游项目 Rook、Ceph 和 NooBaa 组成，它并没有包含在 OCP 订阅中。 OCS 需要自己的订阅，并根据红帽生产支持条款 [5&6] 提供支持。

为了加快推出新功能和程序修复的频率，OCS 的发行节奏与 OCP 次版本的发行节奏不同。 红帽计划以 4 个月的节奏推出 OCS 的新版本，从而为客户提供足够的计划机会。

与 OCP 一致，OCS 在次版本有效期间提供三个支持阶段：全面支持、维护支持和延长更新支持（EUS）。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

在 OCS 处于“完全支持”阶段时，仅在其相应的次版本 OpenShift 以及其后续的次版本处于完全支持阶段时才提供对 OCS 的支持。 对 OCS 的任何级别的支持均受发布它的 OpenShift 的次版本的约束。 在 OCP 的维护或 EUS 阶段之外，不提供对 OCS 或 OCP 的支持。

支持阶段范围

完全支持

对于 OpenShift Container Storage 4.7 版本或更高版本
完全支持阶段从 OCS 次版本的 GA 版本开始，并在 6 个月或下一个次版本的 GA 后 90 天后结束（以较晚的时间为准）。

全面支持会根据公布的“覆盖范围”和“服务等级协议”提供。 同样，开发支持也会根据公布的覆盖范围和服务等级协议提供。

在完全支持阶段中，会发布级别为关键（Critical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序可能会包括在定期发布的更新中。 为了获得安全勘误公告和程序错误修复，客户应将其 OCS 环境升级到最新支持的微版本（4.y.z）。

维护支持

对于 OpenShift Container Storage 4.7 或更高版本
此阶段在相应 GA 的全面支持阶段结束时开始，持续 12 个月。 对于其完全支持阶段超过 6 个月的版本，维护支持阶段的时间将相应减少，从而使完全支持阶段和维护支持阶段的累计时间为 18 个月。

在维护支持阶段中，级别为关键或重要的安全公告（RHSA），以及级别为紧急和精选的高优先级程序错误修复公告（RHBA），一旦可用就会发布。 一般情况下，红帽不会在此阶段发布其他级别的程序错误修复公告和功能增强公告（RHEA）。

在维护支持阶段结束时，软件和文档将继续提供给客户。但是，除提供协助升级到受支持版本的支持外，不会再提供其他任何技术支持。

延长更新支持（EUS）

从 OCS 4.8 开始，红帽将所有次版本号为偶数的次版本（如 4.8、4.10、4.12）作为延长更新支持 (EUS) 版本。

对于 EUS 版本，上述的完全支持和维护支持阶段中的相应条件同样用于决定每个阶段的开始和结束日期。 因此，与非 EUS 版本一致，客户可以预期获得总共 18 个月的支持。 OpenShift Container Platform EUS 版本包括了在 EUS 版本之间更轻松地进行升级的功能，可以简化工作节点的升级过程，并可以通过规划 EUS 到 EUS OpenShift 版本的升级策略来减少因为升级而需要节点进行重新启动的情况。

更多与对 OCS 版本支持的信息包括在 OCS Interoperability Matrix 中。

Red Hat OpenShift support for Windows Containers

从 OpenShift 4.6 开始，Red Hat OpenShift support for Windows Containers 作为其一个可选的组件提供。 Red Hat OpenShift support for Windows Containers 不是 OpenShift Container Platform 订阅的一部分，它需要一个单独的订阅，并遵循红帽生产支持条款进行支持[5＆6] 。

为了增加推出新功能和程序修复的频率，Red Hat OpenShift support for Windows Containers 的发行节奏与 OpenShift Container Platform 次版本的发行节奏会有所不同。 红帽预计每 3 个月发行一次 Red Hat OpenShift support for Windows Containers，在一个 OpenShift 次版本 GA 时，或 GA 后的短期内发布。

Red Hat OpenShift support for Windows Containers 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

对一个 Red Hat OpenShift support for Windows Containers 主版本的支持只限定于一个单独的、特定的 OpenShift Container Platform 次版本，如以下生命周期表中所示。 对 Red Hat OpenShift support for Windows Containers 任何级别的支持都受到发布它的 OpenShift 版本的约束，在 OpenShift 的维护阶段或 EUS 阶段之外，不提供对 Red Hat OpenShift for Windows Containers 或 OpenShift 的支持。

支持阶段范围

Red Hat OpenShift support for Windows Containers 的完全支持阶段始于主版本的 GA 发行日，结束于 Red Hat OpenShift Container Platform for Windows Containers 后续主版本的 GA 发行日。

维护支持阶段始于后续 Red Hat OpenShift support for Windows Containers 主版本 GA 发行日，其结束日期与对应的 Red Hat OpenShift Container Platform 的日期相同。

对于特定的 Red Hat OpenShift support for Windows Containers 版本，会提供延长更新支持（EUS）服务。 这些内容将在本页中介绍，并作为产品发行注记的一部分。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，对一个 Red Hat OpenShift support for Windows Containers 版本提供维护支持服务。

OpenShift Virtualization

从 OpenShift 4.5 开始，OpenShift Virtualization 作为一个可选的安装组件提供。用户可以使用它部署和管理在虚拟机上运行的传统工作负载以及在容器上运行的下一代工作负载。 OpenShift Virtualization 基于上游社区的 kubevirt 项目，并包括在 OpenShift Container Platform 订阅中[7]。

OpenShift Virtualization 的发行时间计划与 OpenShift 次版本的发行节奏保持一致。 红帽计划每 4 个月发布一个 OpenShift Virtualization 版本，从而为客户提供足够时间来计划升级。

OpenShift Virtualization 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

对 OpenShift Virtualization 的支持只适用于其对应的 OpenShift 4 的次版本处于完全支持阶段，且 OpenShift 的后续次版本处于完全支持阶段时，以及 OpenShift Virtualization 处于完全支持阶段时。 对 OpenShift Virtualization 的任何级别的支持均受发布它的 OpenShift 版本的约束。 在 OpenShift 的维护或 EUS 阶段范围外，不会提供 OpenShift Virtualization 或 OpenShift 的支持。

注意：为了保持您的环境的可支持性，并可以利用新的功能和错误修复，您需要使用与您的 OpenShift 版本兼容的 OpenShift Virtualization 版本（如下表所示）。

支持阶段范围

OpenShift Virtualization 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的 3 个月后结束。 3 个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护支持阶段在完全支持阶段结束时马上开始，并在次版本 GA 发行之日起的 18 个月内有效。

特定的 OpenShift Virtualization 发行版本会提供延长更新支持服务。 相关内容会在版本有效时在此页中介绍。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，对一个 OpenShift Virtualization 版本提供维护支持服务。

备注： OpenShift Virtualization 2.7 将为 OpenShift Virtualization 4.8. 这是为了确保版本与相应的 OpenShift 版本保持一致。

OpenShift Logging

从 OpenShift 4.7 开始，Red Hat OpenShift Logging 将作为一个可安装的组件提供，它将具有与核心 OpenShift Container Platform 不同的发行周期。 OpenShift Logging 是一个可选的、可安装的 OpenShift Container Platform 组件，它会按照红帽支持政策进行支持[5&6]。

为了增加推出新功能和程序修复的频率，Red Hat OpenShift Logging 的发行节奏会独立于 OpenShift 次版本的发行节奏。 Openshift Logging 次版本预计将以大约 3 个月的节奏进行发布，取决于每个具体的版本，其发行周期可能会有一些不同。

Red Hat OpenShift Logging 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

在 Red Hat OpenShift Logging 处于“完全支持”阶段时，仅在其相应的次版本 OpenShift 以及其后续的次版本处于完全支持阶段时才提供对 Red Hat OpenShift Logging 的支持。 对 Logging 任何级别的支持都受到发布它的 OpenShift 版本的约束，在 OpenShift 的维护阶段或 EUS 阶段之外，不提供对 LoggingS 或 OpenShift 的支持。

支持阶段范围

OpenShift Logging 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

特定的 OpenShift Logging 发行版本会提供延长更新支持服务。 相关内容会在版本有效时在此页中介绍。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，对一个 OpenShift Logging 版本提供维护支持服务。

网络可观察性

从 OpenShift 4.12 开始，提供了网络可观察性，它是一个可选的、可安装的组件，用于 OpenShift 4.10 及更新的版本。 Network Observability 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。

为了增加推出新功能和程序修复的频率，网络可观察性的发行节奏独立于 OpenShift 次版本的发行节奏。

网络可观察性通过一个单一的滚动流提供，它在 OpenShift 4 的整个生命周期中均受支持。 在 Openshift 4 GA 阶段 1 期间，网络可观察性发行流将持续基于 NetObserv 的稳定上游版本进行更新。 在这个滚动流阶段中，会发布级别为关键（Critical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序会包括在定期发布的更新中。

对网络可观察性的支持从其初始版本开始，在整个 OpenShift 4 GA 阶段 1 期间，滚动流以"完全支持"的形式被支持。 在 OpenShift 4 GA 阶段 2 期间，按 OpenShift 4“维护支持阶段”提供支持。

OpenShift Service Mesh

自 OpenShift 4.1 开始，提供了 OpenShift Service Mesh (OSSM)，它是一个可选的、可安装的组件。 OpenShift Service Mesh 由开源社区上游项目 Istio、Jaeger 和 Kiali 组成，作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。

为了增加推出新功能和程序修复的频率，OpenShift Service Mesh 的发行节奏与OpenShift 次版本的发行节奏不同。 红帽计划以 3 个月的节奏预测 OpenShift Service Mesh 的发行，从而为客户提供足够时间来计划升级。

OpenShift Service Mesh 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

在 OSSM 处于“完全支持”阶段时，仅在其相应的次版本 OpenShift 以及其后续的次版本处于完全支持阶段时才提供对 OpenShift Service Mesh 的支持。 对 OSSM 任何级别的支持都受到发布它的 OpenShift 版本的约束，在 OpenShift 的维护阶段或 EUS 阶段之外，不提供对 OSSM 或 OpenShift 的支持。

支持阶段范围

OSSM 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

特定的 OpenShift Service Mesh 发行版本会提供延长更新支持（EUS）服务。 这些内容将在本页中介绍（标记为 ‘X.Y EUS’），并作为产品发行注记的一部分。 延长更新支持（EUS）服务会在一个 OpenShift 版本的 EUS 有效期间，对一个 OSSM 版本提供维护支持服务。

OpenShift Service Mesh 发行版本可能会受 OpenShift EUS 的支持。 因此，客户可以在一个固定的 OpenShift 版本中维护其OpenShift 集群，并在 OpenShift EUS 的有效期间继续使用 OpenShift Service Mesh 的不同版本。 支持信息中标注了 OpenShift EUS 支持的 OpenShift Service Mesh 版本。

OpenShift Serverless

自 OpenShift 4.3 开始，OpenShift Serverless (OSS) 作为一个可选的、可安装的组件提供。 OpenShift Serverless 由开源社区上游项目 Knative 组成，作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。

为了增加推出新功能和程序修复的频率，OpenShift Serverless 的发行节奏与 OpenShift 次版本的发行节奏不同。 红帽计划以 3 个月的节奏预测 OpenShift Serverless 的发行，从而为客户提供足够时间来计划升级。

OpenShift Serverless 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

另外，红帽将在完全支持阶段和维护支持阶段之外支持 OpenShift Serverless 客户，为他们提供之前版本的 OpenShift Serverless 的问题的帮助和指导。 下表中列出的阶段以外的支持会被限制，因为它不会为该旧版本提供任何程序错误修复、修补或安全漏洞更新。 对 OpenShift Serverless 版本的所有更新都会作为新版本的一部分提供，或在完全支持阶段或维护阶段为发行版本提供补丁。

支持阶段范围

OpenShift Serverless 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后结束。 在此之后，不会对该版本应用任何功能更新或非关键错误修复。 它们将应用于当前的次版本。

OpenShift Serverless 维护支持阶段在版本结束完全支持阶段后立即开始，并持续一个月。 这为客户提供了更新其 Serverless 版本的时间，并提供任何关键错误修复或安全漏洞补丁。

对于特定的 Serverless 发行版本，支持 OpenShift Extended Update Support (EUS) 版本中的 OpenShift Serverless。 为了保持对 Serverless 的支持，客户可能需要更新到经过 EUS 测试的 Serverless 新版本。 当被支持时，这些内容将在本页中，并作为产品发行注记的一部分。

OpenShift Serverless - 支持阶段时间和 OpenShift 支持列表

OpenShift distributed tracing

自 OpenShift 4.3 开始，提供了 OpenShift distributed tracing，它是一个可选的、可安装的组件。 OpenShift distributed tracing 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。

为了增加推出新功能和程序修复的频率，OpenShift distributed tracing 的发行节奏与 OpenShift 次版本的发行节奏不同。

OpenShift distributed tracing 通过一个单一的滚动流提供，它在OpenShift 4 的整个生命周期中均受支持。 在 Openshift 4 GA 阶段 1 期间，distributed tracing 发行流将继续基于 Jaeger 的稳定上游版本。 在这个滚动流阶段中，会发布级别为关键（Critical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序会包括在定期发布的更新中。

对 OpenShift distributed tracing 的支持从其初始版本开始，在整个OpenShift 4 GA 阶段 1 期间，滚动流做为“完全支持阶段”被支持。 在 OpenShift 4 GA 阶段 2 期间，按 OpenShift 4“维护支持阶段”提供支持。

OpenShift GitOps

OpenShift GitOps 是 OpenShift 的一个可选的可安装组件，其中包括上游项目 Argo CD。 OpenShift GitOps 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

为了增加功能更新和修复的频率，OpenShift GitOps 具有独立于 OpenShift 次版本发布流的发布节奏，同时确保每个新的 OpenShift 次版本都具有一个完全支持的 OpenShift GitOps 版本。 红帽计划以 3 个月的节奏预测 OpenShift GitOps 的发行，从而为客户提供足够时间来计划升级。

OpenShift GitOps 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

支持阶段范围

OpenShift GitOps 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

支持的 OpenShift 版本

红帽旨在在最新版本的 OpenShift、最新版本的前一个版本的 OpenShift 以及战略性选择的其他版本的 OpenShift 上提供完全支持的 GitOps 版本。 我们预计无法支持每个版本的 OpenShift。 我们计划对最新版本和被用户广泛使用的版本提供支持。

OpenShift GitOps - 支持阶段时间和 OpenShift 支持列表

OpenShift Pipelines

OpenShift Pipelines 是 OpenShift 的一个可选的可安装组件，其中包括上游项目 Tekton 组件。 OpenShift Pipelines 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

为了增加推出新功能和程序修复的频率，OpenShift Pipelines 的发行节奏与 OpenShift 次版本的发行节奏不同。 红帽计划以 3 个月的节奏预测 OpenShift Pipelines 的发行，从而为客户提供足够时间来计划升级。

OpenShift Pipelines 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

支持阶段范围

OpenShift Pipelines 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

支持的 OpenShift 版本

红帽旨在在最新版本的 OpenShift、最新版本的前一个版本的 OpenShift 以及战略性选择的其他版本的 OpenShift 上提供完全支持的 Pipelines 版本。 （如生命周期表中所示，对于 1.7 及以下的版本，此目标并未完全实现。） 我们预计无法支持每个版本的 OpenShift。 我们计划对最新版本和被用户广泛使用的版本提供支持。

OpenShift GitOps - 支持阶段时间和 OpenShift 支持列表

OpenShift Service Binding Operator

OpenShift Service Binding Operator 是 OpenShift 上的一个可选且可安装的组件，其中包括上游项目 redhat-developer/service-binding-operator。 Service Binding Operator 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

为了增加功能更新和修复的频率，Service Binding Operator 具有独立于 OpenShift 次版本发布流的发布节奏，同时确保每个新的 OpenShift 次版本都具有一个完全支持的 Service Binding Operator 版本。 红帽计划以 3 个月的节奏预测 Service Binding Operator 的发行，从而为客户提供足够时间来计划升级。

Service Binding Operator 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

支持阶段范围

Service Binding Operator 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

支持的 OpenShift 版本

红帽旨在在最新版本的 OpenShift、最新版本的前一个版本的 OpenShift 以及战略性选择的其他版本的 OpenShift 上提供完全支持的 Service Binding Operator 版本。 我们预计无法支持每个版本的 OpenShift。 我们计划对最新版本和被用户广泛使用的版本提供支持。

OpenShift Service Binding Operator - 支持阶段时间和 OpenShift 支持列表

OpenShift Web Terminal Operator

OpenShift Web Terminal Operator 是一个可以在 OpenShift 上安装的可选组件。 OpenShift Web Terminal Operator 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

OpenShift Web Terminal Operator 的发布节奏会独立于 OpenShift 次版本的发布，通常在 OpenShift 之后不久发布。 Red Hat 的目标是在一个新的 OpenShift 次版本或主版本发布后的一个月内，提供兼容版本的 Web Terminal Operator。

OpenShift Web Terminal Operator 提供两个支持阶段；全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

支持阶段范围

OpenShift Web Terminal Operator 全面支持阶段从 GA 发布日期开始，并在其基于的 OpenShift 版本进入维护支持阶段时结束。

维护支持阶段从其基于的 OpenShift 进入维护支持时开始，到底层 OpenShift 结束维护支持时结束。

支持的 OpenShift 版本

Red Hat 旨在为 OpenShift 的每个新的主版本或次版本提供完全支持的 Web Terminal Operator 版本。

OpenShift Web Terminal Operator - 支持阶段时间和 OpenShift 支持列表

OpenShift Dev Spaces / Red Hat CodeReady Workspaces

Red Hat CodeReady Workspaces 已被重新命名为“OpenShift Dev Spaces”。 Dev Spaces 是 OpenShift 的一个可选的可安装组件，其中包括上游项目 Eclipse Che 组件。 Dev Spaces 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

为了增加功能更新和修复的频率，Dev Spaces 具有独立于 OpenShift 次版本发布流的发布节奏，同时确保每个新的 OpenShift 次版本都具有一个完全支持的 Dev Spaces 版本。 红帽计划大约每 6 周发布一次 Dev Spaces，为客户提供充足的升级计划机会。

Dev Spaces 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

支持阶段范围

Dev Spaces 完全支持阶段从次版本的 GA 发布日期开始，并在 Dev Spaces 的后续次版本发布后立即结束。

维护支持阶段在后续 Dev Spaces 版本发布后立即开始，并在 3 个月后结束。

支持的 OpenShift 版本

红帽旨在在最新版本的 OpenShift、最新版本的前一个版本的 OpenShift 以及战略性选择的其他版本的 OpenShift 上提供完全支持的 Dev Spaces 版本。 我们预计无法支持每个版本的 OpenShift。 我们计划对最新版本和被用户广泛使用的版本提供支持。

Red Hat OpenShift Dev Spaces - 支持阶段日期矩阵

Helm

Helm 是在 OpenShift 上安装的一个组件，其中包括来自上游项目 https://helm.sh/ 的组件。 Helm 作为 OpenShift Container Platform 订阅的一部分提供，并根据红帽产品支持条款进行支持。

Helm 支持生命周期遵循随其一起发布的相应 OpenShift 次版本的生命周期。

完全支持：此阶段从次版本的 GA/发布开始，一直持续到相应 OpenShift 次版本的完全支持期结束。

维护支持：此阶段从相应的 OpenShift 次版本进入维护支持阶段开始，一直持续到 OpenShift 次版本维护支持期结束。

OpenShift Application and Cluster Migration Solutions

从 OpenShift 4.2 开始，Cluster Application Migration Tool（CAM）（已被重新命名为 OpenShift Migration Toolkit for Containers (MTC））和 Control Plane Migration Assistant（CPMA）作为可选的、可安装的组件或一组工具程序被提供。用户可以使用它们来帮助进行应用程序工作负载迁移，或将集群从 OpenShift 的一个版本（源）迁移到另一个版本（目标）。

OpenShift Migration Toolkit for Containers 由开源社区上游项目 Velero 和 restic 组成，作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。 每个工具都定义了唯一的支持矩阵，以及每个发布版本的范围。

OpenShift Migration Toolkit for Containers（MTC）

MTC 全面支持阶段从次版本的 GA 发布日期开始，在下一个次版本发布时结束，并开始其维护阶段。 MTC 版本的维护阶段在取代它的次版本正式发行（GA）之后结束。

在完全支持阶段中，会发布级别为关键（Ctitical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序会包括在定期发布的更新中。

支持阶段范围

MTC 旨在支持跨越 6 个次版本的 OpenShift 的迁移功能。 这使客户和合作伙伴可以有效地计划在其环境中如何使用这些工具。 对 MTC 任何级别的支持都受到支持它的 OpenShift 版本的约束，在 OpenShift 支持的阶段之外，不提供对 MTC 或 OpenShift 的支持。

MTC 工具的组件被分为不同部分，以使每个组件可以在不同的 OpenShift 环境（源集群和目标集群），以及不同的 OpenShift 版本中被支持，从而为客户提供了广泛的迁移选项。

MTC 组件根据在什么地方可以安装它们，以及红帽在什么地方支持这些组件的运行，被分为 2 个组件类别。 Migration-UI 和 Migration-Controller 组件只在 ‘目标’ 集群中被支持；Migration-Operator (Velero) 则在 ‘源’ 和 ‘目标’ 集群中都被支持。

OpenShift Migration Toolkit for Containers（MTC）- 支持阶段日期
版本 GA（完全支持） 维护支持 维护支持结束
1.5 支持的 OCP 源集群版本 2020 年 7 月 28 日 2021 年 9 月 29 日 2022 年 8 月 2 日
3.7, 3.9, 3.10, 3.11, 4.4, 4.5, 4.6, 4.7, 4.8
支持的 OCP 目标集群版本
4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8
1.6 支持的 OCP 源集群版本 2021 年 9 月 29 日 2022 年 3 月 24 日 2022 年 8 月 2 日
3.7, 3.9, 3.10, 3.11, 4.4, 4.5, 4.6, 4.7, 4.8
支持的 OCP 目标集群版本
4.6, 4.7, 4.8
1.7 支持的 OCP 源集群版本 2022 年 3 月 24 日 - -
3.11, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
支持的 OCP 目标集群版本
4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12

Control Plane Migration Assistant (CPMA)

CPMA 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束 （大约四个月）。 其重叠的一个月可以允许客户在对现有版本进行升级期间，继续获得全面支持，而无需在此期间使用新发行的版本。

在完全支持阶段中，会发布级别为关键（Ctitical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序会包括在定期发布的更新中。

支持阶段范围

CPMA 工具依赖于 OpenShift 的支持生命周期，并且在所示的 OpenShift 3.x 生命周期之外不受支持。 CPMA 工具将继续获得次版本更新，并且每个发行版本都会声明一个兼容的最低 OCP 版本，直到 OpenShift 3.x 不再被支持（进入生命周期终止阶段）。

CPMA 工具在不同的 OpenShift 环境（源集群和目标集群），以及不同 OpenShift 版本中被支持，从而为用户提供了广泛的迁移选项。 支持的源和目标迁移路径如下所示。

OpenShift Control Plane Migration Assistant (CPMA) - 支持阶段日期
版本 GA（完全支持） 维护支持结束
1.0 支持的 OCP 源集群版本 2019 年 10 月 16 日 2020 年 3 月 6 日
3.7, 3.9, 3.10, 3.11, 4.1, 4.2
支持的 OCP 目标集群版本
4.2
1.1 支持的 OCP 源集群版本 2020 年 2 月 6 日 2020 年 6 月 28 日
3.7, 3.9, 3.10, 3.11
支持的 OCP 目标集群版本
4.1, 4.2, 4.3
1.2 支持的 OCP 源集群版本 2020 年 5 月 28 日 2020 年 10 月 30 日
3.7, 3.9, 3.10, 3.11
支持的 OCP 目标集群版本
4.2、4.3、4.4
1.3（最后发行） 支持的 OCP 源集群版本 2020 年 9 月 30 日 2021 年 3 月 11 日
3.7, 3.9, 3.10, 3.11
支持的 OCP 目标集群版本
4.2, 4.3, 4.4, 4.5, 4.6

Red Hat build of Cryostat

Red Hat build of Cryostat 概述

Red Hat build of Cryostat 是对 OpenShift 上的容器化 JVM 的 JFR 管理工具。 上游社区项目 Cryostat 目前由红帽牵头，以 Universal Permissive License v1.0 的形式发布。

红帽构建的 Cryostat 可通过容器目录获得，Cryostat Operator 可通过 OCP 上的 Red Hat OperatorHub 安装。

以下部分介绍了红帽对 Cryostat 的支持范围。

Red Hat build of Cryostat 权利

OpenJDK 权利提供了对 Red Hat build of Cryostat 的支持。 任何拥有有效 OpenJDK 权利的客户都将获得对 Red Hat build of Cryostat 的支持。

Red Hat build of Cryostat 生命周期和支持政策

Red Hat build of Cryostat 以六个月的节奏发布，最少被支持六个月，并会被后续 Cryostat 版本取代。

Red Hat build of Cryostat 更新

新的 Red Hat build of Cryostat 版本取代以前的 Red Hat build of Cryostat 版本。 旧版本不会有更新。

Red Hat build of Cryostat 生命周期日期

Mirror registry for OpenShift

从 OpenShift 4.9.17 开始，mirror registry for OpenShift 作为可选组件提供，以支持断开连接的安装过程。 Mirror registry for OpenShift 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款[5&6]进行支持。

为了增加推出新功能和程序修复的频率，Mirror registry for OpenShift 的发行节奏与 OpenShift 次版本的发行节奏不同。

Mirror registry for OpenShift 通过一个单一的滚动流提供，它在OpenShift 4 的整个生命周期中均受支持。 在 Openshift 4 GA Phase 1 期间，mirror registry for OpenShift 的发布流会继续基于 Red Hat Quay 的发行版本。 在此期间，会发布级别为关键（Ctitical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA）。 所有其他可用的修复程序和补丁程序通过定期更新发布。 客户需要升级到最新版本的 mirror registry for OpenShift，以便使用最新的修复程序。

对 mirror registry for OpenShift 的支持从其初始版本开始，在整个OpenShift 4 GA 阶段 1 期间，滚动流做为“完全支持阶段”被支持。 在 OpenShift 4 GA 阶段 2 期间，按 OpenShift 4“维护支持阶段”提供支持。 在发布时，mirror registry for OpenShift 支持与处于完整或维护支持阶段的所有 OpenShift Container Platform 4 次要版本一起使用。

OpenShift API for Data Protection

从 OpenShift 4.9 开始，OpenShift API for Data Protection (OADP) 提供了一个可选的、可安装的组件或 API 集，客户、合作伙伴及第三方供应商可以使用它来保护 OpenShift Container Platform (OCP) 上的应用程序工作负载的数据。 这些组件在 OCP 4.6 及更高版本中被工作。

OpenShift API for Data Protection 基于上游社区项目（ Velero 上游组建），作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持[5&6]。 每个工具都定义了唯一的支持矩阵，以及每个发布版本的范围。

OADF 全面支持阶段从次版本的 GA 发布日期开始，在下一个次版本发布时结束，并开始其维护阶段。 OADF 版本的维护阶段在取代它的次版本正式发行（GA）之后结束。

支持阶段范围

OADP 旨在支持跨越 ~4 (X.Y-2/N/X.Y+2) 版本间的 OCP 的备份和恢复功能。 客户和合作伙伴可以有效地备份应用程序的数据并在不同 OCP 版本中恢复它（取决于这些版本中相关的 api）。

OpenShift sandboxed containers

从 OpenShift 4.10 开始，OpenShift 沙盒容器作为可选的可安装组件提供，使客户能够在内核隔离的运行时环境中部署容器。 OpenShift 沙盒容器由上游项目 Kata Containers 组件组成，作为 OpenShift Container Platform 订阅的一部分提供[5,6&7]。

为了增加推出新功能和程序修复的频率，OpenShift 沙盒容器的发行节奏与 OpenShift 次版本的发行节奏不同。

OpenShift 沙盒容器（从 OSC 1.3.2 开始）通过一个单一的滚动流提供，它在 OpenShift 4 的整个生命周期中均受支持。 在 Openshift 4 完全支持阶段，沙盒容器版本流将继续基于 kata-containers 的稳定上游版本进行更新。 在这个滚动流阶段中，会发布级别为关键（Critical）和重要（Important）的安全勘误公告（RHSA），以及优先级为“紧急（Urgent）”和精选的优先级为“高（High）”的程序错误修复公告（RHBA），其它错误修正和补丁程序会包括在定期发布的更新中。

对 OpenShift 沙盒容器的支持从版本 1.3.2 开始，滚动流使用 Full Support 覆盖整个 OpenShift 4 完全支持阶段进行维护。 在 OpenShift 4 维护支持阶段，只为每个 OpenShift 4 维护支持 定义提供支持。

注意：作为第一个发布的版本，OpenShift 沙盒容器 1.2 现已结束其全面支持阶段，建议客户升级到最新可用的版本。

Node Maintenance operator for Red Hat OpenShift

从 OpenShift 4.11 开始，为 Red Hat OpenShift 提供了节点维护 Operator，它是一个可选的、可安装的组件。 Red Hat OpenShift 的节点维护 Operator 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

Red Hat OpenShift 的节点维护 Operator 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 4 个月发布一次 Red Hat OpenShift 的节点维护 Operator。

此 Red Hat OpenShift 的节点维护 Operator 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 Red Hat OpenShift 更新的节点维护 Operator。

Self Node Remediation operator for Red Hat OpenShift

从 OpenShift 4.11 开始，提供 Red Hat OpenShift 的自节点修复 Operator，它是一个可选的、可安装的组件。 Red Hat OpenShift 的自节点修复 Operator 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

Red Hat OpenShift 的自节点修复 Operator 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 4 个月发布一次 Red Hat OpenShift 的自节点维护 Operator。

此 Red Hat OpenShift 的子节点修复 Operator 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 Red Hat OpenShift 更新的子节点修复 Operator。

Node Health Check operator for Red Hat OpenShift

从 OpenShift 4.11 开始，为 Red Hat OpenShift 提供了节点健康检查 Operator，它是一个可选的、可安装的组件。 Red Hat OpenShift 的节点健康检查 Operator 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

Red Hat OpenShift 的节点监控检查 Operator 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 4 个月发布一次 Red Hat OpenShift 的节点健康检查 Operator。

此 Red Hat OpenShift 节点健康检查 operator 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 Red Hat OpenShift 更新的节点健康检查 Operator。

Machine Deletion Remediation operator for Red Hat OpenShift

从 OpenShift 4.13 开始，提供了 machine deletion remediation operator for Red Hat OpenShift，它是一个可选的、可安装的组件。 machine deletion remediation operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅的一部分7提供，并根据红帽产品支持条款进行支持。

machine deletion remediation operator for Red Hat OpenShift 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 4 个月发布一次 machine deletion remediation operator for Red Hat OpenShift。

此 machine deletion remediation operator for Red Hat OpenShift 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 machine deletion remediation operator for Red Hat OpenShift 的更新。

Fence Agents Remediation operator for Red Hat OpenShift

从 OpenShift 4.13 开始，提供 fence agents remediation operator for Red Hat OpenShift，它是一个可选的、可安装的组件。 fence agents remediation operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅7的一部分提供，并根据红帽产品支持条款进行支持。

fence agents remediation operator for Red Hat OpenShift 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 4 个月发布一次 fence agents remediation operator for Red Hat OpenShift。

此 fence agents remediation operator for Red Hat OpenShift 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 fence agents remediation operator for Red Hat OpenShift 的更新。

Cert-manager operator for Red Hat OpenShift

从 OpenShift 4.12 开始，cert-manager Operator for Red Hat OpenShift 将作为一个可安装的组件提供，它将具有与核心 OpenShift Container Platform 不同的发行周期。 cert-manager Operator for Red Hat OpenShift 是一个可选的、可安装的 OpenShift Container Platform 组件，它会按照红帽支持政策进行支持。

为了增加推出新功能和程序修复的频率，cert-manager Operator for Red Hat OpenShift 的发行节奏会独立于 OpenShift 次版本的发行节奏。 cert-manager Operator for Red Hat OpenShift 次版本预计将以大约 3 个月的节奏进行发布，取决于每个具体的版本，其发行周期可能会有一些不同。

Cert-manager Operator for Red Hat OpenShift 在次版本有效期间提供两个支持阶段：全面支持和维护支持。 每个生命周期阶段的支持级别都做为 OpenShift v4 生命周期的一部分表示。

在 cert-manager Operator for Red Hat OpenShift 处于“完全支持”阶段时，仅在其相应的次版本 OpenShift 以及其后续的次版本处于完全支持阶段时才提供对 cert-manager Operator for Red Hat OpenShift 的支持。 对 cert-manager Operator for Red Hat OpenShift 任何级别的支持都受到发布它的 OpenShift 版本的约束，在 OpenShift 的维护阶段或 EUS 阶段之外，不提供对 cert-manager Operator for Red Hat OpenShift 或 OpenShift 的支持。

支持阶段范围

cert-manager Operator for Red Hat OpenShift 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

对于特定的 cert-manager Operator for Red Hat OpenShift 版本，会提供延长更新支持服务。 相关内容会在版本有效时在此页中介绍。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，对一个 cert-manager Operator for Red Hat OpenShift 版本提供维护支持服务。

Secondary Scheduler operator for Red Hat OpenShift

从 OpenShift 4.10 开始，Secondary Scheduler operator for Red Hat OpenShift 作为一个可选、可安装的组件提供。 Secondary Scheduler operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

为了增加推出新功能和程序修复的频率，Secondary Scheduler operator for Red Hat OpenShift 的发行节奏会独立于 OpenShift 次版本的发行节奏。 红帽计划以 3 个月的周期发布新的 Secondary Scheduler operator for Red Hat OpenShift 版本，以包括最新的上游 Secondary Scheduler 版本。

发行和支持计划

NMState operator for Red Hat OpenShift

从 OpenShift 4.10 开始，为 Red Hat OpenShift 提供了 NMState operator，它是一个可选的、可安装的组件。 4.10 版本是 NMState operator 的第一个 GA 版本，当前只适用于裸机平台。 NMState operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

Red Hat OpenShift 的 NMState Operator 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 红帽大约每 3 个月发布一次 Red Hat OpenShift 的 NMState Operator。

此 Red Hat OpenShift 的 NMState Operator 发行版本在整个目标 Red Hat OpenShift 版本的 "Full" 和 "Maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 Red Hat OpenShift 更新的 NMState Operator。

Custom Metric Autoscaler operator for Red Hat OpenShift

Custom Metric Autoscaler operator for Red Hat OpenShift 是一个可选的、可安装的组件。 Custom Metric Autoscaler operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

为了增加推出新功能和程序修复的频率，Custom Metric Autoscaler operator for Red Hat OpenShift 的发行节奏会独立于 OpenShift 次版本的发行节奏。 红帽将每三个月发布一次 Custom Metric Autoscaler operator for Red Hat OpenShift，密切跟踪上游 KEDA 版本。

Custom Metric Autoscaler operator for Red Hat OpenShift 的每个发行版本都会支持四个月。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 Custom Metric Autoscaler operator for Red Hat OpenShift 的更新。

发行和支持计划

多集群引擎

Multicluster Engine for Kubernetes (MCE) operator 是一个软件 operator，它提供了强大的集群管理功能。 multicluster engine for Kubernetes operator 支持跨云和数据中心的 Red Hat OpenShift Container Platform 和 Kubernetes 集群生命周期管理。

用户（如管理员和系统维护工程师等）会面临在不同环境中的一些难题，包括运行 Kubernetes 集群的多个数据中心、私有云以及公共云。multicluster engine for Kubernetes operator 提供了解决这些问题的工具。

支持阶段范围

multicluster engine for Kubernetes 的发行节奏与 Red Hat Advanced Cluster Management (RHACM) 的发行计划匹配，并由 Red Hat Openshift 许可证支持。 完全支持阶段从主版本的 GA 发行之日开始，并在其下一个主 RHACM 版本的 GA 发行之日结束。

维护支持阶段于后续 Red Hat Advanced Cluster Management 主版本 GA 发行之日开始，并与相对应的 RHACM 版本具有相同的结束时间。

逻辑卷管理器存储 operator

从 OpenShift 4.12 开始，提供了 Red Hat OpenShift 的逻辑卷管理器存储，它是一个可选的、可安装的组件。 Red Hat OpenShift 的逻辑卷管理器存储作为 OpenShift Container Platform 订阅[7] 的一部分提供，并根据红帽产品支持范围进行支持。

逻辑卷管理器存储 operator 的发布旨在与 OpenShift 次版本发布节奏保持一致。 红帽计划每 3 个月发布一个逻辑卷管理器存储版本，从而为客户提供足够时间来计划升级。

支持阶段范围

Operator for Red Hat OpenShift 的逻辑卷管理器存储的完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的下一个月结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

对于特定的 Red Hat OpenShift 逻辑卷存储器版本，会提供延长更新支持服务。 相关内容会在版本有效时在此页中介绍。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，为 Red Hat OpenShift 的逻辑卷管理器存储提供维护支持服务。

发行和支持计划

Run Once Duration Override operator for Red Hat OpenShift

从OpenShift 4.13开始，run once duration override operator for Red Hat OpenShift 作为一个可选的、可安装的组件使用。 run once duration override operator for Red Hat OpenShift 作为 OpenShift Container Platform 订阅[7]的一部分提供，并根据红帽产品支持条款进行支持。

run once duration override operator for Red Hat OpenShift 的发行节奏独立于 Red Hat OpenShift Container Platform 次版本的发行节奏，但通常它们的发行节奏是一致的。 run once duration override operator for Red Hat OpenShift 的发布节奏取决于需要实现的代码修复或新功能。

此 run once duration override operator for Red Hat OpenShift 发行版本在整个目标 Red Hat OpenShift 版本的 "full" 和 "maintenance" 生命周期阶段内被支持。 要继续获得程序错误修复和新功能，客户需要升级到较新版本的 Operator。 这可能意味着，还需要升级 OpenShift 次版本，以便继续获得 run once duration override operator for Red Hat OpenShift 的更新。

发行和支持计划

Kernel Module Management operator for Red Hat OpenShift

从 OpenShift 4.12 开始提供了 kernel module management operator for Red Hat OpenShift。它是一个可选的、可安装的组件。 Red Hat OpenShift 的内核模块管理 Operator 作为 OpenShift Container Platform 订阅[7] 的一部分提供，并根据红帽产品支持范围进行支持。

为了增加推出新功能和程序修复的频率，kernel module management operator for Red Hat OpenShift 的发行节奏会独立于 OpenShift 次版本的发行节奏。 红帽计划以 3 个月的周期发布新的 kernel module management operator for Red Hat OpenShift 版本，以包括最新的上游内存模块管理的版本。

支持阶段范围

kernel module management operator for Red Hat OpenShift 完全支持阶段从次发行版本的 GA 发行之日开始，并在其下一个次发行版本 GA 后的一个月后结束（大约四个月）。 一个月的重叠期使客户能够在两个次版本之间保持完整的支持阶段。

维护阶段从后续第一个次版本 GA/发行后的一个月开始，直到后续第 3 个次版本的发行之日结束。

对于特定的 kernel module management operator for Red Hat OpenShift 版本，会提供延长更新支持服务。 相关内容会在版本有效时在此页中介绍。 延长更新支持服务会在一个 OpenShift 版本的 EUS 有效期间，对 kernel module management operator for Red Hat OpenShift 提供维护支持服务。

发行和支持计划

备注

  1. 当出现对您的业务造成重大影响的问题时，红帽可能会选择在最终的程序补丁还在开发的同时，提供一个热修补程序来作为一个临时的解决方案。
  2. 软件功能的增强主要由主发行版本和次发行版本提供。 集合（Rollup）、更新及补丁主要用于提供对程序错误的修正。
  3. 最新安全更新信息：https://access.redhat.com/site/security/updates/
  4. 红帽会提供影响级别为关键的安全修复以及精选的级别为紧急的程序错误修复。
  5. 覆盖范围：https://access.redhat.com/support/offerings/production/soc/
  6. 服务等级协议：https://access.redhat.com/support/offerings/production/sla
  7. 仅限于特定体系结构。
  8. RHEL CoreOS 版本的信息包括在：https://access.redhat.com/articles/4128421
  9. 为了对要被取代的 OpenShift EUS 版本提供的额外重叠期，OpenShift 4.6 EUS 结束日期延长至 2022 年 10 月 27 日
  10. EUS 生命周期的历史信息包括在延长更新支持 (EUS) 概述页
  11. 技术预览：https://access.redhat.com/support/offerings/techpreview