第 2 章 了解 OpenShift Container Platform 更新
在 OpenShift Container Platform 4 中，您可以使用 Web 控制台或 OpenShift CLI(oc)使用单一操作来更新 OpenShift Container Platform 集群。当一个更新可用于其集群时，平台管理员会自动获得通知。
OpenShift Update Service(OSUS)根据 registry 中的发行镜像构建了一个更新可能性图。该图基于特定版本的推荐、经过测试的更新路径。OpenShift Container Platform 集群连接到红帽混合云服务器，并确定用户正在运行的集群以及版本信息。OSUS 使用已知更新目标的信息做出响应。集群管理员或自动更新控制器都会编辑 Cluster Version Operator(CVO)的自定义资源(CR)，以及要升级到的新版本。在 CVO 从 registry 接收更新镜像后，CVO 会应用更改。
之前通过 Operator Lifecycle Manager (OLM) 安装的 Operator 会遵循不同的更新过程。如需更多信息，请参阅更新安装的 Operator。
2.1. 关于 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 和一个或多个应用程序实例组成。
