第 1 章 了解 OpenShift 更新
1.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) 会更新集群中每个节点的操作系统和配置。
1.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频道中，这样做可以有更长的时间来发行在更新中可能存在的风险。 -
在这个延迟后，
fast频道中可用的发行版本始终在stable频道中可用。
如果更新存在已知问题，这意味着什么？
- 红帽会持续评估来自多个来源的数据，以确定从一个版本更新到另一个版本是否会出现问题。发现的问题通常记录在版本的发行注记中。即使更新路径中存在已知的问题，客户进行更新仍被支持。
红帽不会阻止用户升级到特定版本。红帽可能会声明条件更新风险，这些风险可能不适用于特定集群。
- 声明的风险提供有关受支持更新的更多上下文。集群管理员仍可接受该特定目标版本的风险和更新。
如果特定版本的更新不再被推荐意味着什么？
- 如果因为回归的问题，红帽从任何支持的发行版本中删除更新建议，则会为更正回归的未来版本提供取代的更新建议。当缺陷被修正、测试并提升到您选择的频道时，可能会有延迟。
什么时候下一个 z-stream 版本会在 fast 和 stable 频道中出现？
虽然特定节奏可能会因多个因素而异，但对最新次版本的新 z-stream 版本通常会每周提供。随着时间推移，旧的次版本变得更稳定，可能需要更长的时间才提供新的 z-stream 版本。
重要它们仅根据 z-stream 版本的相关数据进行估算。红帽保留根据需要更改发行频率的权利。任何数量的问题都可能导致此发行节奏出现异常和延迟。
-
发布 z-stream 版本后，它也会出现在该次版本的
fast频道中。延迟后，z-stream 版本可能会出现在该次版本的stable频道中。
其他资源
1.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 根据 topology.kubernetes.io/zone 标签，按区字母更新受影响的节点。如果一个区域有多个节点，则首先更新最旧的节点。对于不使用区的节点，如裸机部署中的节点，节点会按使用的时间更新，首先更新最旧的节点。MCO 一次更新机器配置池中由 maxUnavailable 字段指定的节点数量。然后，MCO 会应用新配置并重启机器。
对于 OpenShift Container Platform 中的所有机器配置池，maxUnavailable 的默认设置是 1。建议您不要更改这个值，且一次只更新一个 control plane 节点。对于 control plane 池，请不要将这个值改为 3。
如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker，MCO 不会在这些机器上更新 kubelet，因为您必须首先在这些机器上更新 OpenShift API。
当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更新。但是，因为已设置了最大不可用节点数，所以可以在一定机器无法使用的情况下，确保正常的集群操作。
OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。
1.1.3. 了解集群 Operator 条件类型
集群 Operator 的状态包括它们的 condition 类型，它告知您 Operator 的健康状况的当前状态。以下定义涵盖了一些常见 ClusterOperator 条件类型的列表。省略了具有额外条件类型和特定 Operator 语言的 Operator。
Cluster Version Operator (CVO) 负责从集群 Operator 收集状态条件，以便集群管理员可以更好地了解 OpenShift Container Platform 集群的状态。
-
available: 条件类型
Available表示 Operator 功能且在集群中可用。如果状态是False，则操作对象中的至少一个部分无法正常工作，并且条件要求管理员干预。 progressing: 条件类型
Progressing表示 Operator 正在主动推出新的代码、传播配置更改，或者从一个稳定状态移到另一个状态。当 Operator 协调之前已知状态时，Operator 不会报告条件类型
Progressing为True。如果观察到的集群状态已更改，且 Operator 会响应它，则状态将报告为True，因为它从一个 steady 状态移到另一个状态。Degraded：条件类型
Degraded表示 Operator 具有在一段时间内不匹配其所需状态的当前状态。周期可能会因组件而异，但Degraded状态代表 Operator 条件的持久性观察。因此，Operator 不会波动处于 Degraded 状态和没有处于Degraded状态。如果从一个状态转换到另一个状态的过渡在长时间内没有保留，则可能会有一个不同的条件类型来报告
Degraded。Operator 在正常更新过程中不会报告Degraded。Operator 可能会报告Degraded，以响应需要最终管理员干预的持久性基础架构失败。注意此条件类型仅表示可能需要调查和调整某项。只要 Operator 可用，
Degraded条件就不会造成用户工作负载失败或应用程序停机。Upgradeable: 条件类型
Upgradeable表示 Operator 是否根据当前的集群状态安全更新。message 字段包含管理员对集群成功更新需要执行的操作的人类可读描述。当此条件为True、Unknown或缺失时，CVO 允许更新。当
Upgradeable状态为False时，只有次版本更新会受到影响，CVO 会阻止集群执行受影响的更新，除非强制（强制）更新。
1.1.4. 了解集群版本状况类型
Cluster Version Operator (CVO) 监控集群 Operator 和其他组件，并负责收集集群版本及其 Operator 的状态。此状态包括条件类型，它告知您 OpenShift Container Platform 集群的健康状态和当前状态。
除了 Available,Progressing, 和 Upgradeable 外，还有影响集群版本和 Operator 的条件类型。
-
Failing：集群版本状况类型
Failing表示集群无法访问其所需状态，不健康，需要管理员干预。 -
Invalid: 集群版本条件类型
Invalid表示集群版本具有阻止服务器执行操作的错误。只要设置了此条件，CVO 仅协调当前状态。 -
RetrievedUpdates ：集群版本条件类型
RetrievedUpdates表示已从上游更新服务器检索可用更新。在检索前条件为Unknown，如果更新最近失败或无法检索，则为False；如果availableUpdates字段是最新且准确的，则为True。 -
ReleaseAccepted ：集群版本状况类型
ReleaseAccepted，并带有True状态表示请求的发行版本有效负载在镜像验证和预条件检查过程中没有失败。 -
ImplicitlyEnabledCapabilities ：集群版本条件类型
ImplicitlyEnabledCapabilities具有True状态，表示用户目前没有通过spec.capabilities请求的功能。如果任何相关资源之前由 CVO 管理，CVO 不支持禁用功能。
1.1.5. 常见术语
- 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)概述。
