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

第 3 章 执行集群更新

download PDF

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 页面的顶部会显示一个警报。您仍然可以更新到当前当前使用的次发行版本的下一个可用补丁更新。
  • 检查 Kubernetes 1.28 中删除的 API 列表，将任何受影响的组件迁移到使用新的 API 版本，并提供管理员确认。如需更多信息，请参阅准备升级到 OpenShift Container Platform 4.16。
  • 如果您运行 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

    注意
    • 如果没有推荐的更新，则已知问题的更新可能仍然可用。如需更多信息，请参阅更新条件更新路径。
    • 有关如何执行 EUS 到 EUS 频道升级的详情，请参阅附加资源部分中列出的 准备执行 EUS 升级 页面。

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

    $ oc adm upgrade channel <channel>

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

    $ oc adm upgrade channel stable-4.16
    重要

    对于生产环境中的集群，您必须订阅一个 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.29.4
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.29.4
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.29.4
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.29.4
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.29.4
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.29.4

3.1.5. 使用 oc adm upgrade status 检索集群更新的信息（技术预览）

在更新集群时，了解您更新的过程会很有用。oc adm upgrade 命令返回有关更新状态的有限信息，在这个版本引入了 oc adm upgrade status 命令作为一个技术预览功能。这个命令将状态信息与 oc adm upgrade 命令分离，并提供集群更新的具体信息，包括 control plane 和 worker 节点更新的状态。

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

重要

oc adm upgrade status 命令只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

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

    例 3.1. 成功更新进度的输出示例

    = 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

    通过这些信息，您可以对如何进行更新做出明智的决策。

其他资源

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

您可以使用 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.7. 使用 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.