了解更新渠道和版本 - 了解 OpenShift 更新 | 更新集群 | OpenShift Container Platform 4.17

更新渠道

更新渠道是用户声明他们打算将其集群更新到的 OpenShift Container Platform 次要版本的机制。它们还允许用户通过 `fast`、`stable`、`candidate` 和 `eus` 渠道选项选择其更新的时机和支持级别。集群版本操作符使用基于渠道声明以及其他条件信息的更新图，来提供可用于集群的推荐更新和条件更新列表。

更新渠道对应于 OpenShift Container Platform 的次要版本。渠道中的版本号表示集群最终将更新到的目标次要版本，即使它高于集群当前的次要版本。

例如，OpenShift Container Platform 4.10 更新渠道提供以下建议：

4.10 内的更新。
4.9 内的更新。
从 4.9 更新到 4.10，允许所有 4.9 集群最终更新到 4.10，即使它们没有立即满足最低 z 流版本要求。
仅 `eus-4.10`：4.8 内的更新。
仅 `eus-4.10`：从 4.8 更新到 4.9 再到 4.10，允许所有 4.8 集群最终更新到 4.10。

4.10 更新渠道不建议更新到 4.11 或更高版本。此策略确保管理员必须明确决定更新到下一个 OpenShift Container Platform 次要版本。

更新渠道仅控制发行版的选取，不影响您安装的集群版本。特定版本的 OpenShift Container Platform 的 `openshift-install` 二进制文件始终安装该版本。

OpenShift Container Platform 4.17 提供以下更新渠道：

stable-4.17
`eus-4.y`（仅适用于 EUS 版本，旨在促进 EUS 版本之间的更新）
fast-4.17
candidate-4.17

如果您不希望集群版本操作符 (Cluster Version Operator, CVO) 从更新推荐服务获取可用更新，可以使用 OpenShift CLI 中的 `oc adm upgrade channel` 命令配置一个空渠道。例如，如果集群的网络访问受到限制，并且没有可访问的本地更新推荐服务，此配置将非常有用。

Red Hat 建议仅更新到 OpenShift 更新服务建议的版本。对于次要版本更新，版本必须是连续的。Red Hat 不测试对非连续版本的更新，并且不能保证与早期版本的兼容性。

更新渠道

fast-4.17 渠道

一旦 Red Hat 将某个版本声明为通用可用 (GA) 版本，`fast-4.17` 渠道就会使用 OpenShift Container Platform 4.17 的新版本进行更新。因此，这些版本完全受支持，并旨在用于生产环境。

stable-4.17 渠道

虽然 `fast-4.17` 渠道会在发布勘误表后立即包含版本，但版本会在延迟后添加到 `stable-4.17` 渠道。在此延迟期间，将从多个来源收集数据并进行分析，以查找产品回归的迹象。一旦收集到大量数据点，这些版本就会添加到稳定渠道。

由于获得大量数据点所需的时间因许多因素而异，因此不提供 fast 和 stable 渠道之间延迟时间的服务级别目标 (SLO)。有关更多信息，请参阅“为您的集群选择正确的渠道”。

新安装的集群默认使用稳定渠道。

eus-4.y 渠道

除了稳定渠道外，OpenShift Container Platform 的所有偶数次要版本都提供扩展更新支持 (EUS)。提升到稳定渠道的版本也会同时提升到 EUS 渠道。EUS 渠道的主要目的是为了方便执行仅控制平面更新的集群。

标准订阅者和非 EUS 订阅者都可以访问所有 EUS 存储库和必要的 RPM（`rhel-*-eus-rpms`），以便支持诸如调试和构建驱动程序之类的关键用途。

candidate-4.17 渠道

`candidate-4.17` 渠道提供对版本的早期访问（不受支持），这些版本在构建后即可使用。仅在候选渠道中提供的版本可能不包含最终 GA 版本的完整功能集，或者在 GA 之前可能会删除功能。此外，这些版本尚未经过 Red Hat 全面的质量保证，可能无法提供更新路径以升级到以后的 GA 版本。鉴于这些注意事项，候选渠道仅适用于测试目的，其中销毁和重新创建集群是可以接受的。

渠道中的更新建议

OpenShift Container Platform 保持一个更新推荐服务，该服务知道您安装的 OpenShift Container Platform 版本以及在渠道中获取下一个版本的路径。更新路径也仅限于与您当前选择的渠道及其推广特性相关的版本。

您可以想象在您的渠道中看到以下版本：

4.17.0
4.17.1
4.17.3
4.17.4

该服务仅推荐经过测试且没有已知严重回归的更新。例如，如果您的集群使用的是 4.17.1，而 OpenShift Container Platform 建议使用 4.17.4，则建议从 4.17.1 更新到 4.17.4。

不要依赖连续的补丁编号。在此示例中，4.17.2 在该渠道中不可用，也从未可用，因此不建议或不支持更新到 4.17.2。

更新建议和条件更新

Red Hat 在受支持的渠道中添加新发布的版本和与这些版本关联的更新路径之前和之后都会对其进行监控。

如果 Red Hat 从任何受支持的版本中删除更新建议，则会提供对纠正回归的未来版本的替代更新建议。但是，在缺陷得到纠正、测试并提升到您选择的渠道之前，可能会有延迟。

从 OpenShift Container Platform 4.10 开始，当确认更新风险时，它们将被声明为相关更新的条件更新风险。每个已知的风险可能适用于所有集群，或者仅适用于匹配特定条件的集群。一些示例包括将 `Platform` 设置为 `None` 或将 CNI 提供程序设置为 `OpenShiftSDN`。集群版本操作符 (CVO) 会持续评估已知风险与当前集群状态是否匹配。如果没有任何风险匹配，则建议进行更新。如果风险匹配，则将这些更新路径标记为“已知问题的更新”，并提供指向已知问题的参考链接。参考链接可帮助集群管理员决定是否要接受风险并继续更新其集群。

当 Red Hat 选择声明条件更新风险时，该操作将同时在所有相关渠道中执行。条件更新风险的声明可能发生在更新被提升到受支持的渠道之前或之后。

为您的集群选择正确的渠道

选择合适的渠道涉及两个决定。

首先，选择您希望用于集群更新的次要版本。选择与当前版本匹配的渠道可确保您仅应用 z 流更新，并且不会收到功能更新。选择版本大于当前版本的可用渠道将确保在一次或多次更新后，您的集群将更新到该版本。您的集群将仅提供与其当前版本、下一个版本或下一个 EUS 版本匹配的渠道。

由于规划跨越多个次要版本的更新非常复杂，因此不提供辅助规划单个仅控制平面更新之外的更新的渠道。

其次，您应该选择所需的部署策略。您可以选择在 Red Hat 声明版本为 GA 时立即更新（通过选择快速通道），也可以等待 Red Hat 将版本提升到稳定通道。fast-4.17 和 stable-4.17 中提供的更新建议都得到完全支持，并且同样受益于持续的数据分析。将版本提升到稳定通道之前的延迟是这两个通道之间的唯一区别。最新 z-streams 的更新通常会在 1-2 周内提升到稳定通道，但是最初将更新部署到最新的次要版本的延迟要长得多，通常为 45-90 天。在选择所需通道时，请考虑此提升延迟，因为等待提升到稳定通道可能会影响您的调度计划。

此外，还有一些因素可能导致组织永久或暂时将集群迁移到快速通道，包括：

希望立即应用已知会影响您环境的特定修复程序。
立即应用 CVE 修复程序。CVE 修复程序可能会引入回归，因此 z-streams 的 CVE 修复程序仍然适用提升延迟。
内部测试流程。如果您的组织需要几周时间才能验证版本，最好与我们的提升流程同时进行测试，而不是等待。这还可以确保提供给 Red Hat 的任何遥测信号都被纳入我们的部署中，以便更快地解决与您相关的问题。

受限网络集群

如果您自己管理 OpenShift Container Platform 集群的容器镜像，则必须查阅与产品版本相关的 Red Hat 勘误，并注意任何影响更新的注释。在更新期间，用户界面可能会警告您在这些版本之间切换，因此您必须确保在绕过这些警告之前选择了合适的版本。

通道切换

可以通过 Web 控制台或 adm upgrade channel 命令切换通道。

$ oc adm upgrade channel <channel>

如果您切换到不包含当前版本的通道，Web 控制台将显示警报。在没有当前版本的通道上，Web 控制台不建议进行任何更新。但是，您可以随时返回到原始通道。

更改通道可能会影响集群的可支持性。可能适用以下条件：

如果您从 stable-4.17 通道切换到 fast-4.17 通道，您的集群仍然受支持。
您可以随时切换到 candidate-4.17 通道，但该通道的一些版本可能不受支持。
如果您当前版本是通用可用版本，则可以从 candidate-4.17 通道切换到 fast-4.17 通道。
您可以随时从 fast-4.17 通道切换到 stable-4.17 通道。如果当前版本最近已提升，则该版本提升到 stable-4.17 可能需要最多一天的延迟。

其他资源