第 2 章 准备更新集群
2.1. 准备升级到 OpenShift Container Platform 4.15
了解更多有关集群管理员必须执行的任务才能成功初始化更新，以及确保成功更新的可选准则。
2.1.1. RHEL 9.2 微架构要求的变化
OpenShift Container Platform 现在基于 RHEL 9.2 主机操作系统。现在，微架构要求增加到 x86_64-v2、Power9 和 Z14。请参阅 RHEL 微架构要求文档。您可以按照这个 KCS 文章中所述的步骤在更新前验证兼容性。
如果没有正确的微架构要求，更新过程将失败。请确定为每个构架购买正确的订阅。如需更多信息，请参阅 Red Hat Enterprise Linux 入门 - 其他构架
2.1.2. Kubernetes API 删除
OpenShift Container Platform 4.15 中没有删除 Kubernetes API。
2.1.3. 评估条件更新的风险
条件更新 是一个更新目标，它可用，但不推荐因为应用到集群的已知风险而不推荐。Cluster Version Operator (CVO)会定期查询 OpenShift Update Service (OSUS)以获取有关更新建议的最新数据，一些潜在的更新目标可能会存在与其关联的风险。
CVO 评估条件风险，如果风险不适用于集群，则目标版本作为集群的推荐更新路径提供。如果风险被决定适用，或者因为 CVO 无法评估风险，则更新目标作为条件更新可供集群使用。
当您试图更新到目标版本时遇到条件更新时，您必须评估将集群更新至该版本的风险。通常，如果您没有特定需要更新到该目标版本，则最好等待红帽推荐的更新路径。
但是，如果您对升级到该版本有很大的理由，例如，如果您需要修复一个重要的 CVE，则修复 CVE 的好处可能会超过集群更新的风险。您可以完成以下任务来确定您是否同意红帽对更新风险的评估：
- 在非生产环境中完成广泛的测试，以让您轻松在生产环境中完成更新。
- 按照条件更新描述中提供的链接，调查程序错误，并确定它是否可能会导致集群出现问题。如果您需要帮助了解风险，请联系红帽支持团队。
其他资源
2.1.4. 集群更新前的 etcd 备份
etcd 备份记录集群状态及其所有资源对象。您可以使用备份来尝试在灾难情况下恢复集群状态，因为您无法恢复其当前无法正常工作状态的集群。
在更新上下文中，如果更新引入的灾难性条件在没有恢复到以前的集群版本的情况下无法修复的灾难性条件，您可以尝试进行 etcd 恢复。etcd 恢复可能被破坏并降级到正在运行的集群，则只使用它们作为最后的手段。
因此，etcd 恢复不应用作回滚解决方案。当前还不支持将集群还原到以前的版本。如果您的更新无法完成，请联系红帽支持。
有几个因素会影响 etcd 恢复的可行性。如需更多信息，请参阅"恢复 etcd 数据"和"恢复到以前的集群状态"。
其他资源
2.1.5. 集群更新的最佳实践
OpenShift Container Platform 提供了可靠的更新体验，可最大程度降低更新期间的工作负载中断。除非集群在更新请求时处于可升级状态，否则更新将不会启动。
这个设计在启动更新前强制实施一些关键条件，您也可以采取其他多个措施来提高成功集群更新的机会。
2.1.5.1. 选择 OpenShift Update Service 推荐的版本
OpenShift Update Service (OSUS) 根据集群特征（如集群订阅频道）提供更新建议。Cluster Version Operator 会将这些推荐保存为推荐的或有条件的更新。虽然可以尝试更新到 OSUS 不推荐的版本，但按照推荐的更新路径进行防止在集群中出现已知的问题或意外后果。
仅选择 OSUS 建议的更新目标以确保成功更新。
2.1.5.2. 解决集群中的所有关键警报
关键警报必须尽快解决，但在启动集群更新前，务必要解决这些警报并解决所有问题。在开始更新前无法解决关键警报可能会导致集群出现有问题的条件。
在 web 控制台的 Administrator 视角中，进入到 Observe
2.1.5.3. 确保集群处于 Upgradable 状态
当一个或多个 Operator 在一个小时内没有报告其 Upgradeable 条件为 True 时，在集群中会触发 ClusterNotUpgradeable 警告警报。在大多数情况下，此警报并不会阻止补丁更新，但您无法执行次版本更新，直到您解决了这个警报，所有 Operator 都报告 Upgradeable 为 True。
如需有关 Upgradeable 条件的更多信息，请参阅额外资源部分中的 "了解集群 Operator 条件类型"。
2.1.5.4. 确保有足够的备用节点可用
集群不应在没有备用节点容量的情况下运行，特别是在启动集群更新时。没有运行且可用的节点可能会限制集群在对集群工作负载造成最小影响的情况下执行更新的能力。
根据集群的 maxUnavailable spec 配置的值，如果是一个不可用节点，集群可能无法对该节点应用机器配置更改。另外，如果计算节点没有足够的备用容量，当第一个节点进行更新时，工作负载可能无法临时转移到另一个节点上。
确保每个 worker 池中有足够的可用节点，以及计算节点上有足够的备用容量，以提高节点更新成功的机会。
对于 OpenShift Container Platform 中的所有机器配置池，maxUnavailable 的默认设置是 1。建议您不要更改这个值，且一次只更新一个 control plane 节点。对于 control plane 池，请不要将这个值改为 3。
2.1.5.5. 确保正确配置了集群的 PodDisruptionBudget
您可以使用 PodDisruptionBudget 对象定义任意给定时间必须可用的 pod 副本的最小数量或百分比。此配置可防止工作负载在集群进行维护操作（例如进行集群更新）时出现中断。
但是，可以为给定的拓扑配置 PodDisruptionBudget，以防止节点在集群更新过程中排空和更新。
在规划集群更新时，检查 PodDisruptionBudget 对象的配置以了解以下因素：
-
对于高可用性工作负载，请确保有可以临时离线的副本，而不会被
PodDisruptionBudget禁止。 -
对于不是高用的工作负载，请确保它们不受
PodDisruptionBudget保护，或者有一些替代机制来排空这些工作负载，如定期重启或有保证的最终终止。
其他资源
