准备更新到 OpenShift Container Platform 4.17

OpenShift Container Platform 现在基于 RHEL 9.2 主机操作系统。微架构要求现已提高到 x86_64-v2、Power9 和 Z14。请参阅RHEL 微架构要求文档。您可以按照此KCS 文章中概述的步骤，在更新前验证兼容性。

OpenShift Container Platform 4.17 中没有 Kubernetes API 删除。

条件更新是指可用的但由于适用于您的集群的已知风险而未推荐的更新目标。集群版本操作符 (CVO) 定期查询 OpenShift 更新服务 (OSUS) 以获取有关更新建议的最新数据，并且某些潜在的更新目标可能存在相关风险。

CVO 会评估条件风险，如果这些风险不适用于集群，则该目标版本将作为集群的推荐更新路径提供。如果确定风险适用，或者由于某种原因 CVO 无法评估风险，则该更新目标将作为条件更新提供给集群。

当您在尝试更新到目标版本时遇到条件更新时，您必须评估将集群更新到该版本的风险。通常，如果您没有特别需要更新到该目标版本，最好等待 Red Hat 提供推荐的更新路径。

但是，如果您有充分的理由更新到该版本，例如，如果您需要修复重要的 CVE，则修复 CVE 的好处可能超过更新对您的集群造成问题的风险。您可以完成以下任务来确定您是否同意 Red Hat 对更新风险的评估

etcd 备份记录了集群及其所有资源对象的状态。在灾难场景下，如果无法恢复当前故障状态的集群，可以使用备份尝试恢复集群状态。

在更新上下文中，如果更新引入了灾难性条件，而无需回滚到之前的集群版本就无法修复，则可以尝试对集群进行 etcd 恢复。etcd 恢复可能会破坏正在运行的集群并使其不稳定，仅在万不得已时才使用。

有几个因素会影响 etcd 恢复的可行性。有关更多信息，请参阅“备份 etcd 数据”和“恢复到以前的集群状态”。

OpenShift Container Platform 提供了强大的更新体验，可在更新期间最大限度地减少工作负载中断。除非集群在发出更新请求时处于可升级状态，否则更新不会开始。

此设计在启动更新之前强制执行一些关键条件，但您可以采取许多措施来增加集群更新成功的几率。