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

第 3 章 执行集群更新

3.1. 使用 CLI 更新集群

您可以使用 OpenShift CLI (oc)在 OpenShift Container Platform 集群上执行次要版本和补丁更新。

3.1.1. 先决条件

  • 使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限。
  • 具有最新的 etcd 备份，以防因为升级失败需要将集群恢复到以前的状态。
  • 如果因为 pod 失败需要恢复持久性卷，请确定已有一个最新的 Container Storage Interface (CSI) 卷快照。
  • 您的 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不支持对 RHEL worker 的 从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。
  • 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新至与目标发行版本兼容的版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时，它们有有效的升级路径。如需了解如何检查兼容性以及更新 已安装的 Operator 的更多信息，请参阅更新已安装的 Operator。
  • 确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略，可以暂停 MCP。
  • 如果您的集群使用手动维护的凭证，请更新新发行版本的云供应商资源。如需更多信息，包括如何确定这是集群的要求，请参阅准备使用手动维护的凭证更新集群。
  • 确保解决所有 Upgradeable=False 条件，以便集群可以更新到下一个次版本。当您有一个或多个无法更新的集群 Operator 时，Cluster Settings 页面的顶部会显示一个警报。您仍然可以更新到当前当前使用的次发行版本的下一个可用补丁更新。
  • 如果您运行 Operator 或您已配置了 pod 中断预算，您可能会在升级过程中遇到中断。如果在 PodDisruptionBudget 中将 minAvailable 设置为 1，则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点，则所有 pod 只能有一个节点上运行，PodDisruptionBudget 字段可能会阻止节点排空。
重要
  • 当更新无法完成时，Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成，请联系红帽支持。
  • 使用 unsupportedConfigOverrides 部分修改 Operator 配置不受支持，并可能会阻止集群更新。您必须在更新集群前删除此设置。

其他资源

3.1.2. 暂停 MachineHealthCheck 资源

在更新过程中，集群中的节点可能会临时不可用。对于 worker 节点，机器健康检查可能会认为这样的节点不健康，并重新引导它们。为避免重新引导这样的节点，请在更新集群前暂停所有 MachineHealthCheck 资源。

先决条件

  • 安装 OpenShift CLI (oc) 。

流程

  1. 要列出您要暂停的所有可用 MachineHealthCheck 资源，请运行以下命令： 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. 要暂停机器健康检查，请将 cluster.x-k8s.io/paused="" 注解添加到 MachineHealthCheck 资源。运行以下命令: 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

    注解的 MachineHealthCheck 资源类似以下 YAML 文件： 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    重要

    更新集群后恢复机器健康检查。要恢复检查，请运行以下命令从 MachineHealthCheck 资源中删除暂停注解： 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

3.1.3. 关于更新单个节点 OpenShift Container Platform

您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。

但请注意以下限制：

  • 不需要暂停 MachineHealthCheck 资源，因为没有其他节点可以执行健康检查。
  • 不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是，最好在升级失败时执行 etcd 备份。如果 control plane 健康，您可以使用备份将集群恢复到以前的状态。

  • 更新单节点 OpenShift Container Platform 集群需要停机，并可包括自动重启。停机时间取决于更新有效负载，如下例所示：

    • 如果更新有效负载包含操作系统更新（需要重启），则停机时间会非常显著，并影响集群管理和用户工作负载。
    • 如果更新包含不需要重启的机器配置更改，则停机时间会减少，并且对集群管理和用户工作负载的影响会减少。在这种情况下，节点排空步骤会通过单节点 OpenShift Container Platform 跳过，因为集群中没有其他节点可以重新调度工作负载。
    • 如果更新有效负载不包含操作系统更新或机器配置更改，则会出现简短的 API 中断并快速解决。
重要

某些条件（如更新的软件包中的错误）可能会导致单个节点在重启后无法重启。在这种情况下，更新不会自动回滚。

其他资源

3.1.4. 使用 CLI 更新集群

您可以使用 OpenShift CLI (oc) 来检查和请求集群更新。

您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。

先决条件

  • 安装与更新版本的版本匹配的 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。
  • 暂停所有 MachineHealthCheck 资源。

流程

  1. 查看可用更新，记录下要应用的更新的版本号： 

    $ oc adm upgrade

    输出示例

    Cluster version is 4.13.10
Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
Recommended updates:
  VERSION     IMAGE
  4.13.14     quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
  4.13.13     quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
  4.13.12     quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
  4.13.11     quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd

    注意
    • 如果没有可用的更新，则支持的更新可能仍可用。如需更多信息，请参阅更新条件更新路径。
    • 有关如何执行 Control Plane Only 更新的详情和信息，请参阅附加资源部分中列出的 准备执行 Control Plane Only 更新页。

  2. 根据您的机构要求，设置适当的升级频道。例如，您可以将频道设置为 stable-4.13 或 fast-4.13。有关频道的更多信息，请参阅在额外资源项中的了解更新频道和发行版本。 

    $ oc adm upgrade channel <channel>

    例如，要将频道设置为 stable-4.15 ： 

    $ oc adm upgrade channel stable-4.15
    重要

    对于生产环境中的集群，您必须订阅一个 stable-*、eus-* 或 fast-* 频道。

    注意

    当您准备好升级到下一个次版本时，请选择与该次版本对应的频道。声明更新频道后，集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所有可用的更新，并提供最佳更新建议。更新建议可能会随时间变化，因为它们基于哪些更新选项。

    如果您无法看到到目标次版本的更新路径，请保持将集群更新至当前版本的最新补丁版本，直到下一个次版本在路径中可用。

  3. 应用更新：

    • 要更新到最新版本： 

      $ oc adm upgrade --to-latest=true 1

    • 要更新到一个特定版本： 

      $ oc adm upgrade --to=<version> 1
      1 1
      <version> 是从 oc adm upgrade 命令的输出中获取的更新版本。
      重要

      使用 oc adm upgrade --help 时，会列出 --force 的选项。强烈不鼓励这样做，因为使用 --force 选项会绕过集群端保护，包括版本验证和预条件检查。使用 --force 不保证成功更新。绕过保护会使集群面临风险。

  4. 查看 Cluster Version Operator 的状态： 

    $ oc adm upgrade

  5. 更新完成后，可以通过以下方法确认集群已更新为新版本： 

    $ oc adm upgrade

    输出示例

    Cluster version is <version>

Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)

No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.

  6. 如果您要将集群升级到下一个次版本，如 X.y 升级到 X. (y+1)，建议在部署依赖新功能的工作负载前确认您的节点已升级： 

    $ oc get nodes

    输出示例

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.28.5
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.28.5
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.28.5
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.28.5
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.28.5
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.28.5

其他资源

3.1.5. 通过一个条件更新路径进行更新

您可以使用 Web 控制台或 OpenShift CLI (oc) 更新推荐的条件更新路径。当集群不推荐进行条件更新时，您可以使用 OpenShift CLI (oc) 4.10 或更高版本作为条件更新路径进行更新。

流程

  1. 因为存在风险而不推荐的更新，您可以使用以下命令查看它的描述信息： 

    $ oc adm upgrade --include-not-recommended

  2. 如果集群管理员已评估了潜在的已知风险，并确定这些风险对于当前集群是可接受的，管理员可以执行以下命令来忽略这些安全保护并继续更新： 

    $ oc adm upgrade --allow-not-recommended --to <version> <.>

    <.> <version>是从上一个命令输出中获取的被支持但不推荐的更新版本。

其他资源

3.1.6. 使用 CLI 更改更新服务器

更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS)，您必须将服务器的 URL 设置为 upstream，以便在更新期间使用本地服务器。upstream 的默认值是 https://api.openshift.com/api/upgrades_info/v1/graph。

流程

  • 更改集群版本中的 upstream 参数值： 

    $ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge

    <update-server-url> 变量指定更新服务器的 URL。

    输出示例

    clusterversion.config.openshift.io/version patched

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.