支持控制台（Console）开发人员开始试用联系人

第 2 章 准备更新集群

2.1. 准备升级到 OpenShift Container Platform 4.16

了解更多有关集群管理员必须执行的任务才能成功初始化更新，以及确保成功更新的可选准则。

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.16 使用 Kubernetes 1.29，它删除了几个已弃用的 API。

集群管理员必须在从 OpenShift Container Platform 4.15 升级到 4.16 前提供手动确认。这有助于防止升级到 OpenShift Container Platform 4.16 后出现问题，其中已删除的 API 仍在由运行或与集群交互的工作负载、工具或其他组件使用。管理员必须针对将要删除的任何 API 评估其集群，并迁移受影响的组件，以使用适当的新 API 版本。完成此评估和迁移后，管理员可以进行确认。

在将 OpenShift Container Platform 4.15 集群更新至 4.16 之前，您必须提供管理员确认。

2.1.2.1. 删除的 Kubernetes API

OpenShift Container Platform 4.16 使用 Kubernetes 1.29，它删除了以下已弃用的 API。您必须迁移清单和 API 客户端以使用适当的 API 版本。有关迁移删除 API 的更多信息，请参阅 Kubernetes 文档。

表 2.1. 从 Kubernetes 1.29 中删除的 API
资源删除的 API迁移到主要变化

FlowSchema

flowcontrol.apiserver.k8s.io/v1beta2

flowcontrol.apiserver.k8s.io/v1 或 flowcontrol.apiserver.k8s.io/v1beta3

否

PriorityLevelConfiguration

flowcontrol.apiserver.k8s.io/v1beta2

flowcontrol.apiserver.k8s.io/v1 或 flowcontrol.apiserver.k8s.io/v1beta3

是

2.1.2.2. 为删除的 API 评估集群

有多种方法可帮助管理员确定将使用移除的 API 的位置。但是，OpenShift Container Platform 无法识别所有实例，尤其是使用闲置或外部工具的工作负载。管理员负责针对已删除 API 实例正确评估所有工作负载和其他集成。

2.1.2.2.1. 查看警报以识别已删除 API 的使用

当使用 API 时会触发两个警报，该 API 将在以后的版本中删除：

  • APIRemovedInNextReleaseInUse - 针对将在下一个 OpenShift Container Platform 发行版本中删除的 API。
  • APIRemovedInNextEUSReleaseInUse - 针对将在下一个 OpenShift Container Platform 扩展更新支持（EUS）版本中删除的 API。

如果其中任何一个警报在集群中触发，请查看警报并采取措施通过迁移清单和 API 客户端以使用新的 API 版本来清除警报。

使用 APIRequestCount API 获取有关使用哪些 API 的更多信息，以及哪些工作负载正在使用删除的 API，因为警报不提供此信息。此外，一些 API 可能不会触发这些警报，但仍然被 APIRequestCount 捕获。将警报调优为不太敏感，以避免在生产环境中出现警报。

2.1.2.2.2. 使用 APIRequestCount 来识别已删除 API 的使用

您可以使用 APIRequestCount API 来跟踪 API 请求，并检查它们中的任何请求是否使用其中一个已删除的 API。

先决条件

  • 您必须可以使用具有 cluster-admin 角色的用户访问集群。

流程

  • 运行以下命令并检查输出的 REMOVEDINRELEASE 列以确定当前正在使用的 API: 

    $ oc get apirequestcounts

    输出示例

    NAME                                                                 REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
...
flowschemas.v1beta2.flowcontrol.apiserver.k8s.io                     1.29               0                       3
...
prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io     1.29               0                       1
...

    重要

    您可以安全地忽略结果中出现的以下条目：

    • system:serviceaccount:kube-system:generic-garbage-collector 和 system:serviceaccount:kube-system:namespace-controller 用户可能会出现在结果中，因为这些服务在搜索要删除的资源时调用所有注册的 API。
    • system:kube-controller-manager 和 system:cluster-policy-controller 用户可能会出现在结果中，因为它们在强制执行各种策略时遍历所有资源。

    您还可以使用 -o jsonpath 来过滤结果： 

    $ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'

    输出示例

    1.29	flowschemas.v1beta2.flowcontrol.apiserver.k8s.io
1.29	prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io

2.1.2.2.3. 使用 APIRequestCount 来识别哪些工作负载正在使用删除的 API

您可以检查给定 API 版本的 APIRequestCount 资源，以帮助识别正在使用 API 的工作负载。

先决条件

  • 您必须可以使用具有 cluster-admin 角色的用户访问集群。

流程

  • 运行以下命令并检查 username 和 userAgent 字段，以帮助识别使用 API 的工作负载： 

    $ oc get apirequestcounts <resource>.<version>.<group> -o yaml

    例如： 

    $ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io -o yaml

    您还可以使用 -o jsonpath 从 APIRequestCount 资源中提取 username 和 userAgent 值： 

    $ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io \
  -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
  | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT

    输出示例

    VERBS     USERNAME                            USERAGENT
create    system:admin                        oc/4.13.0 (linux/amd64)
list get  system:serviceaccount:myns:default  oc/4.16.0 (linux/amd64)
watch     system:serviceaccount:myns:webhook  webhook/v1.0.0 (linux/amd64)

2.1.2.3. 迁移已删除 API 实例

有关如何迁移删除 Kubernetes API 的详情，请参阅 Kubernetes 文档中的已弃用 API 迁移指南。

2.1.2.4. 管理员确认

在为任何已删除的 API 评估集群并迁移了任何删除 API 后，您可以确认集群已准备好从 OpenShift Container Platform 4.15 升级到 4.16。

警告

请注意，管理员须负责确保已移除 API 的所有使用都已根据需要得到解决和迁移，然后再提供此管理员的确认。OpenShift Container Platform 可以协助评估，但无法识别所有可能移除的 API 的使用，特别是空闲的工作负载或外部工具。

先决条件

  • 您必须可以使用具有 cluster-admin 角色的用户访问集群。

流程

  • 运行以下命令，确认您已完成评估，集群已准备好在 OpenShift Container Platform 4.16 中删除 Kubernetes API： 

    $ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.15-kube-1.29-api-removals-in-4.16":"true"}}' --type=merge

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.2. 解决集群中的所有关键警报

关键警报必须尽快解决，但在启动集群更新前，务必要解决这些警报并解决所有问题。在开始更新前无法解决关键警报可能会导致集群出现有问题的条件。

在 web 控制台的 Administrator 视角中，进入到 Observe Alerting 来查找关键警报。

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 保护，或者有一些替代机制来排空这些工作负载，如定期重启或有保证的最终终止。

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.