第 3 章 了解 OpenShift 更新
3.1. OpenShift 更新简介
在 OpenShift Container Platform 4 中，您可以使用 Web 控制台或 OpenShift CLI (oc) 使用单一操作来更新 OpenShift Container Platform 集群。平台管理员可以通过转至 web 控制台中的 Administration oc adm upgrade 命令的输出来查看新的更新选项。
红帽托管了一个公共 OpenShift Update Service (OSUS)，它根据官方 registry 中的 OpenShift Container Platform 发行镜像提供更新可能性图。图包含任何公共 OCP 版本的更新信息。OpenShift Container Platform 集群默认配置为连接到 OSUS，OSUS 会使用已知更新目标的信息响应集群。
当集群管理员或自动更新控制器使用新版本编辑 Cluster Version Operator (CVO) 的自定义资源 (CR) 时，更新开始。要将集群与新指定版本协调，CVO 从镜像 registry 检索目标发行镜像，并开始将更改应用到集群。
之前通过 Operator Lifecycle Manager (OLM) 安装的 Operator 会遵循不同的更新过程。如需更多信息，请参阅更新安装的 Operator。
目标发行镜像包含组成特定 OCP 版本的所有集群组件的清单文件。当将集群更新至新版本时，CVO 会在称为 Runlevels 的独立阶段应用清单。大多数（但不是全部清单）支持其中一个集群 Operator。当 CVO 将清单应用到集群 Operator 时，Operator 可能会执行更新任务将其与新的指定版本协调。
CVO 监控每个应用的资源的状态，以及所有集群 Operator 报告的状态。只有活跃 Runlevel 中的所有清单和集群 Operator 都达到稳定条件时，CVO 才会继续更新。在 CVO 通过此过程更新整个 control plane 后，Machine Config Operator (MCO) 会更新集群中每个节点的操作系统和配置。
3.1.1. 有关更新可用性的常见问题
OpenShift Container Platform 集群使用更新时，有几个因素会影响到 OpenShift Container Platform 集群。以下列表提供有关更新可用性的常见问题：
每个更新频道之间有什么区别？
-
一个新的发行版本最初添加到
candidate频道中。 -
在成功测试后，
candidate频道的发行版本将提升到fast频道，则会发布勘误，并完全支持该发行版本。 延迟后，
fast频道中的一个发行版本最终会提升到stable频道。这个延迟代表了fast和stable频道之间的唯一区别。注意对于最新的 z-stream 版本，这个延迟通常是一周或两周。但是，初始更新到最新次版本的延迟可能需要更长的时间，通常为 45-90 天。
-
提升到
stable频道的版本同时提升到eus频道。eus频道的主要目的是，为了方便执行 EUS 到 EUS 更新的集群。
stable 频道安全或大于 fast 频道中的一个发行版本吗？
-
如果在
fast频道中为发行版本发现了回归问题，它将被解析为与stable频道中发布的回归问题相同的扩展。 -
fast和stable频道中发行版本的唯一区别在于，一个发行版本仅会在出现在fast频道一段时间后才会出现在stable频道中，这样做可以有更长的时间来发行在更新中可能存在的风险。
如果一个更新被支持但不推荐使用意味着什么？
- 红帽会持续评估来自多个源的数据，以确定从一个版本更新到另一个版本是否会导致问题。如果确定了问题，用户可能不再建议更新路径。但是，即使不推荐更新路径，如果客户执行了更新，仍然被支持。
红帽不会阻止用户升级到特定版本。红帽可能会声明条件更新风险，这些风险可能不适用于特定集群。
- 声明的风险提供有关受支持更新的更多上下文。集群管理员仍可接受该特定目标版本的风险和更新。虽然在条件风险上下文中不推荐使用这个更新。
如果特定版本的更新不再被推荐意味着什么？
- 如果因为回归的问题，红帽从任何支持的发行版本中删除更新建议，则会为更正回归的未来版本提供取代的更新建议。当缺陷被修正、测试并提升到您选择的频道时，可能会有延迟。
什么时候下一个 z-stream 版本会在 fast 和 stable 频道中出现？
虽然特定节奏可能会因多个因素而异，但对最新次版本的新 z-stream 版本通常会每周提供。随着时间推移，旧的次版本变得更稳定，可能需要更长的时间才提供新的 z-stream 版本。
重要它们仅根据 z-stream 版本的相关数据进行估算。红帽保留根据需要更改发行频率的权利。任何数量的问题都可能导致此发行节奏出现异常和延迟。
-
发布 z-stream 版本后，它也会出现在该次版本的
fast频道中。延迟后，z-stream 版本可能会出现在该次版本的stable频道中。
其他资源
3.1.2. 关于 OpenShift Update 服务
OpenShift Update Service (OSUS) 为 OpenShift Container Platform 提供推荐的更新，包括 Red Hat Enterprise Linux CoreOS (RHCOS)。它提供了一个图表，其中包含组件 Operator 的顶点（vertices）和连接它们的 边（edges）。图中的边代表了您可以安全更新到的版本。顶点是更新的有效负载，用于指定受管集群组件的预期状态。
集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务，并根据当前组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时，CVO 使用对应的发行镜像来更新集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。
为了让 OpenShift Update Service 仅提供兼容的更新，可以使用一个版本验证管道来驱动自动化过程。每个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本后，OpenShift Update Service 会通知您它可用。
OpenShift Update Service 显示当前集群的所有推荐更新。如果 OpenShift Update Service 不建议升级路径，这可能是因为更新或目标发行版本存在已知问题。
两个控制器在持续更新模式下运行。第一个控制器持续更新有效负载清单，将清单应用到集群，并输出 Operator 的受控推出的状态，以指示它们是否处于可用、升级或失败状态。第二个控制器轮询 OpenShift Update Service，以确定更新是否可用。
仅支持更新到较新的版本。不支持将集群还原或回滚到以前的版本。如果您的更新失败，请联系红帽支持。
在更新过程中，Machine Config Operator(MCO)将新配置应用到集群机器。MCO 会处理由 maxUnavailable 字段指定的、协调机器配置池中的节点数量，并将它们标记为不可用。在默认情况下，这个值被设置为 1。然后，MCO 会应用新配置并重启机器。
如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker，MCO 不会在这些机器上更新 kubelet，因为您必须首先在这些机器上更新 OpenShift API。
当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更新。但是，因为已设置了最大不可用节点数，所以可以在一定机器无法使用的情况下，确保正常的集群操作。
OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。
3.1.3. 常见术语
- Control plane（控制平面）
- control plane 由 control plane 机器组成，负责管理 OpenShift Container Platform 集群。control plane 机器管理计算机器（也被称为 worker）上的工作负载。
- Cluster Version Operator
- Cluster Version Operator (CVO)启动集群的更新过程。它根据当前的集群版本检查 OSUS，并检索包含可用或可能的更新路径的图形。
- Machine Config Operator
- Machine Config Operator (MCO)是一个集群级别的 Operator，用于管理操作系统和机器配置。通过 MCO，平台管理员可以配置和更新 worker 节点上的 systemd、CRI-O 和 Kubelet、内核、NetworkManager 和其他系统功能。
- OpenShift 更新服务
- OpenShift Update Service (OSUS)为 OpenShift Container Platform 提供无线更新，包括 Red Hat Enterprise Linux CoreOS(RHCOS)。它提供了一个图形或图表，其中包含组件 Operator 的顶点和连接它们的边。
- Channels
- Channels 声明了一个与 OpenShift Container Platform 次版本相关的更新策略。OSUS 使用这个配置的策略来推荐与该策略一致更新边缘。
- 推荐的更新边缘
- 推荐的更新边缘 是 OpenShift Container Platform 发行版本之间的建议更新。建议使用给定的更新，具体取决于集群配置的频道、当前版本、已知的错误和其他信息。OSUS 将建议的边缘与 CVO 通信，后者在每个集群中运行。
- 延长更新支持
所有 post-4.7 甚至编号的次版本都标记为 延长更新支持 (EUS)版本。这些版本包括了在 EUS 版本之间更轻松地更新路径，可以简化 worker 节点的更新，并可以通过规划 EUS-to-EUS OpenShift Container Platform 版本的更新策略来减少重启 worker 节点的更新。
如需更多信息，请参阅 Red Hat OpenShift Extended Update Support(EUS)概述。
3.1.4. 其他资源
- 有关更新过程的每个主要方面的详情，请参考集群如何更新工作。
