×

先决条件

  • 以具有 admin 权限的用户身份访问集群。请参阅 使用 RBAC 定义和应用权限

  • 如果更新失败并且必须将集群恢复到以前的状态,则需要最近的 etcd 备份

  • 如果需要由于 Pod 故障而恢复持久卷,则需要最近的 容器存储接口 (CSI) 卷快照

  • 您的 RHEL7 工作节点已替换为 RHEL8 或 RHCOS 工作节点。Red Hat 不支持对 RHEL 工作节点进行 RHEL7 到 RHEL8 的就地更新;必须使用干净的操作系统安装替换这些主机。

  • 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新到与目标版本兼容的版本。更新 Operator 可确保在集群更新期间默认 OperatorHub 目录从当前次要版本切换到下一个次要版本时,它们具有有效的更新路径。有关如何检查兼容性以及如何在必要时更新已安装的 Operator 的更多信息,请参阅更新已安装的 Operator

  • 确保所有机器配置池 (MCP) 都正在运行且未暂停。更新过程中会跳过与已暂停 MCP 关联的节点。如果您正在执行金丝雀发布更新策略,则可以暂停 MCP。

  • 如果您的集群使用手动维护的凭据,请更新新版本的云提供商资源。有关更多信息(包括如何确定这是否是集群的要求),请参阅准备更新使用手动维护凭据的集群

  • 确保解决所有Upgradeable=False 条件,以便集群允许更新到下一个次要版本。当您有一个或多个无法更新的集群 Operator 时,会在**集群设置**页面顶部显示警报。您仍然可以更新到当前使用的次要版本的下一个可用补丁更新。

  • 如果您运行 Operator 或使用 Pod disruption budget 配置任何应用程序,则在更新过程中可能会遇到中断。如果在PodDisruptionBudget中将minAvailable设置为 1,则会排空节点以应用挂起的机器配置,这可能会阻止驱逐进程。如果重新引导多个节点,所有 Pod 都可能只在一个节点上运行,并且PodDisruptionBudget字段可以阻止节点排空。

  • 如果更新未能完成,集群版本 Operator (CVO) 会在尝试协调更新时报告任何阻塞组件的状态。不支持将集群回滚到以前的版本。如果更新未能完成,请联系 Red Hat 支持。

  • 使用unsupportedConfigOverrides部分修改 Operator 的配置不受支持,并且可能会阻止集群更新。您必须在更新集群之前删除此设置。

暂停 MachineHealthCheck 资源

在更新过程中,集群中的节点可能会暂时不可用。对于工作节点,机器运行状况检查可能会将此类节点识别为不健康并重新引导它们。为了避免重新引导这些节点,请在更新集群之前暂停所有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-

关于更新单节点 OpenShift Container Platform

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

但是,请注意以下限制:

  • 暂停MachineHealthCheck资源的先决条件不需要,因为没有其他节点可以执行运行状况检查。

  • 使用 etcd 备份恢复单节点 OpenShift Container Platform 集群不受官方支持。但是,最好执行 etcd 备份,以防更新失败。如果您的控制平面运行状况良好,则可以使用备份将集群恢复到以前的状态。

  • 更新单节点 OpenShift Container Platform 集群需要停机时间,并且可能包括自动重启。停机时间取决于更新负载,如下面的场景所述:

    • 如果更新负载包含需要重新引导的操作系统更新,则停机时间很长,会影响集群管理和用户工作负载。

    • 如果更新包含不需要重新引导的机器配置更改,则停机时间较短,对集群管理和用户工作负载的影响减轻。在这种情况下,由于集群中没有其他节点可以将工作负载重新调度到,因此单节点 OpenShift Container Platform 会跳过节点排空步骤。

    • 如果更新负载不包含操作系统更新或机器配置更改,则会发生短暂的 API 中断,并很快解决。

某些情况(例如更新的软件包中的错误)会导致单节点在重新引导后无法重新启动。在这种情况下,更新不会自动回滚。

其他资源

使用 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
    • 如果没有推荐的更新,仍然可以使用存在已知问题的更新。有关更多信息,请参阅沿条件更新路径更新

    • 有关如何执行“仅控制平面”更新的详细信息和信息,请参阅“其他资源”部分中列出的准备执行“仅控制平面”更新页面。

  2. 根据您的组织要求,设置合适的更新渠道。例如,您可以将渠道设置为stable-4.13fast-4.13。有关渠道的更多信息,请参阅“其他资源”部分中列出的了解更新渠道和版本

    $ oc adm upgrade channel <channel>

    例如,要将渠道设置为stable-4.17

    $ oc adm upgrade channel stable-4.17

    对于生产集群,您必须订阅stable-*eus-*fast-*渠道。

    当您准备好转到下一个次要版本时,请选择与该次要版本相对应的渠道。更新渠道声明得越早,集群就能越有效地向您的目标版本推荐更新路径。集群可能需要一些时间来评估所有可用的更新选项,并提供最佳的更新建议供您选择。更新建议会随着时间的推移而改变,因为它们基于当时可用的更新选项。

    如果您看不到到目标次要版本的更新路径,请继续将集群更新到当前版本的最新补丁版本,直到下一个次要版本在路径中可用。

  3. 应用更新

    • 要更新到最新版本:

      $ oc adm upgrade --to-latest=true (1)
    • 要更新到特定版本:

      $ oc adm upgrade --to=<version> (1)
      1 <version>是您从oc adm upgrade命令的输出中获得的更新版本。

      使用oc adm upgrade --help时,列出了--force选项。这**强烈不建议**,因为使用--force选项会绕过集群端防护措施,包括版本验证和前提条件检查。使用--force不能保证成功更新。绕过防护措施会使集群面临风险。

  4. 查看集群版本 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.30.3
    ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.30.3
    ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.30.3
    ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.30.3
    ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.30.3
    ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.30.3

使用 oc adm upgrade status 收集集群更新状态(技术预览版)

更新集群时,了解更新进度非常有用。虽然 oc adm upgrade 命令仅返回有关更新状态的有限信息,但此版本引入了 oc adm upgrade status 命令作为技术预览版功能。此命令将状态信息与 oc adm upgrade 命令解耦,并提供有关集群更新的具体信息,包括控制平面和工作节点更新的状态。

oc adm upgrade status 命令是只读命令,不会更改集群中的任何状态。

oc adm upgrade status 命令仅为技术预览版功能。技术预览版功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览版功能的支持范围的更多信息,请参阅 技术预览版功能支持范围

oc adm upgrade status 命令可用于从 4.12 版本到最新支持版本的集群。

虽然您的集群不需要是启用技术预览版的集群,但您必须启用 OC_ENABLE_CMD_UPGRADE_STATUS 技术预览版环境变量,否则 OpenShift CLI (oc) 将无法识别该命令,您将无法使用该功能。

步骤
  1. 通过运行以下命令将 OC_ENABLE_CMD_UPGRADE_STATUS 环境变量设置为 true

    $ export OC_ENABLE_CMD_UPGRADE_STATUS=true
  2. 运行 oc adm upgrade status 命令

    $ oc adm upgrade status
    更新成功进行的示例输出
    = Control Plane =
    Assessment:      Progressing
    Target Version:  4.14.1 (from 4.14.0)
    Completion:      97%
    Duration:        54m
    Operator Status: 32 Healthy, 1 Unavailable
    
    Control Plane Nodes
    NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
    ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
    ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
    ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
    
    = Worker Upgrade =
    
    = Worker Pool =
    Worker Pool:     worker
    Assessment:      Progressing
    Completion:      0%
    Worker Status:   3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded
    
    Worker Pool Nodes
    NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
    ip-10-0-4-159.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
    ip-10-0-20-162.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
    ip-10-0-99-40.us-east-2.compute.internal    Outdated      Pending    4.14.0    ?
    
    = Worker Pool =
    Worker Pool:     infra
    Assessment:      Progressing
    Completion:      0%
    Worker Status:   1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded
    
    Worker Pool Node
    NAME                                             ASSESSMENT    PHASE      VERSION   EST    MESSAGE
    ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.14.0    +10m
    
    = Update Health =
    SINCE   LEVEL   IMPACT   MESSAGE
    14m4s   Info    None     Update is proceeding well

    有了这些信息,您可以根据情况做出如何继续更新的明智决定。

沿着条件更新路径进行更新

您可以使用 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> (1)
    1 <version> 是您从先前命令的输出中获得的更新版本,该版本受支持,但也存在已知问题或风险。

使用 CLI 更改更新服务器

更改更新服务器是可选的。如果您已安装并配置了本地 OpenShift 更新服务 (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