更新集群

1. 目标版本存储在 ClusterVersion 资源的 spec.desiredUpdate.version 字段中，该字段可通过 Web 控制台或 CLI 进行管理。
2. Cluster Version Operator (CVO) 检测到 ClusterVersion 资源中的 desiredUpdate 与当前集群版本不同。使用 OpenShift Update Service 中的图形数据，CVO 将所需的集群版本解析为发行镜像的 pull spec。
3. CVO 验证发行镜像的完整性和真实性。红帽通过使用镜像 SHA 摘要作为唯一和不可变发行镜像标识符，发布有关在预定义位置发布的发行镜像的加密签名的声明。CVO 使用内置公钥列表来验证与检查的发行镜像匹配的声明是否存在和签名。
4. CVO 在 openshift-cluster-version 命名空间中创建一个名为 version-$version-$hash 的作业。此作业使用执行发行镜像的容器，因此集群通过容器运行时下载镜像。然后，作业会将清单和元数据从发行镜像提取到 CVO 访问的共享卷。
5. CVO 验证提取的清单和元数据。
6. CVO 检查一些 preconditions，以确保集群中没有检测到有问题的条件。某些条件可能会阻止更新进行。这些条件可以由 CVO 本身决定，或由单个集群 Operator 报告，用于检测 Operator 认为更新问题的一些集群详情。
7. CVO 以 status.desired 记录接受的发行版本，并创建一个有关新更新的 status.history 条目。
8. CVO 开始协调来自发行镜像的清单。集群 Operator 在称为 Runlevels 的独立阶段更新，CVO 确保 Runlevel 中的所有 Operator 在进入下一级别前完成更新。
9. CVO 本身的清单会在进程早期应用。应用 CVO 部署时，当前的 CVO pod 会停止，并使用新版本启动的 CVO pod。新的 CVO 继续协调剩余的清单。
10. 更新会进行，直到整个 control plane 更新至新版本。单个集群 Operator 可能会在集群域中执行更新任务，但它们通过 Progressing=True 条件报告其状态。
11. Machine Config Operator (MCO) 清单应用到进程末尾。然后，更新的 MCO 开始更新每个节点的系统配置和操作系统。每个节点可能会在开始重新接受工作负载前排空、更新和重启。

1. cordon 和 drain 节点

   注意

   当节点被封锁时，工作负载无法调度到其中。

2. 更新节点的系统配置和操作系统 (OS)
3. 重新引导节点
4. 取消协调节点

1. MCO 会处理节点 1、2 和 3，并开始排空它们。
2. 节点 2 完成排空、重启并再次可用。MCO 对节点 4 进行 cordons，并开始排空节点。
3. 节点 1 完成排空、重新引导并再次可用。MCO 对节点 5 进行 cordons，并开始排空节点。
4. 节点 3 完成排空、重启并再次可用。
5. 节点 5 完成排空、重启并再次可用。
6. 节点 4 完成排空、重启并再次可用。

流程

1. 运行以下命令，获取您要应用的更新的 pull spec：

   $ oc adm upgrade

   这个命令的输出包括 pull specs 用于可用的更新，如下所示：

   输出部分示例

   ...
   Recommended updates:
   
   VERSION IMAGE
   4.17.0  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
   ...

2. 运行以下命令，使用您要使用的发行镜像设置 $RELEASE_IMAGE 变量：

   $ RELEASE_IMAGE=<update_pull_spec>

   其中 <update_pull_spec> 是您要使用的发行镜像的 pull spec。例如：

   quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032

3. 运行以下命令，从 OpenShift Container Platform 发行镜像中提取 CredentialsRequest 自定义资源 (CR) 列表：

   $ oc adm release extract \
     --from=$RELEASE_IMAGE \
     --credentials-requests \
     --included \1
     --to=<path_to_directory_for_credentials_requests> 2

   1

   --included 参数只包含目标发行版本所需的特定集群配置的清单。

   2

   指定要存储 CredentialsRequest 对象的目录的路径。如果指定的目录不存在，这个命令会创建它。

   此命令为每个 CredentialsRequest 对象创建一个 YAML 文件。

4. 对于发行镜像中的每个 CredentialsRequest CR，请确保集群中存在与 spec.secretRef.namespace 字段中的文本匹配的命名空间。此字段是保存凭证配置的生成的 secret 的位置。

   AWS CredentialsRequest 对象示例

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: cloud-credential-operator-iam-ro
     namespace: openshift-cloud-credential-operator
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - effect: Allow
         action:
         - iam:GetUser
         - iam:GetUserPolicy
         - iam:ListAccessKeys
         resource: "*"
     secretRef:
       name: cloud-credential-operator-iam-ro-creds
       namespace: openshift-cloud-credential-operator 1

   1

   此字段指示必须存在的命名空间来保存生成的 secret。

   其他平台的 CredentialsRequest CR 具有与不同平台值类似的格式。

5. 对于任何集群的 CredentialsRequest CR 还没有在 spec.secretRef.namespace 中指定的命名空间，运行以下命令创建命名空间：

   $ oc create namespace <component_namespace>

流程

1. 运行以下命令，为 OpenShift Container Platform 发行镜像设置变量：

   $ RELEASE_IMAGE=$(oc get clusterversion -o jsonpath={..desired.image})

2. 运行以下命令，从 OpenShift Container Platform 发行镜像获取 CCO 容器镜像：

   $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)

   注意

   确保 $RELEASE_IMAGE 的架构与将使用 ccoctl 工具的环境架构相匹配。

3. 运行以下命令，将 CCO 容器镜像中的 ccoctl 二进制文件提取到 OpenShift Container Platform 发行镜像中：

   $ oc image extract $CCO_IMAGE \
     --file="/usr/bin/ccoctl.<rhel_version>" \1
     -a ~/.pull-secret

   1

   对于 <rhel_version>，请指定与主机使用的 Red Hat Enterprise Linux (RHEL) 版本对应的值。如果没有指定值，则默认使用 ccoctl.rhel8。以下值有效：

   • rhel8: 为使用 RHEL 8 的主机指定这个值。
   • rhel9 ：为使用 RHEL 9 的主机指定这个值。

4. 运行以下命令更改权限以使 ccoctl 可执行：

   $ chmod 775 ccoctl.<rhel_version>

流程

1. 通过为您的云供应商运行 命令，使用 ccoctl 工具处理所有 CredentialsRequest 对象。以下命令处理 CredentialsRequest 对象：

   例 2.1. Amazon Web Services (AWS)

   $ ccoctl aws create-all \1
     --name=<name> \2
     --region=<aws_region> \3
     --credentials-requests-dir=<path_to_credentials_requests_directory> \4
     --output-dir=<path_to_ccoctl_output_dir> \5
     --create-private-s3-bucket 6

   1

   要单独创建 AWS 资源，请使用"使用自定义"内容在 AWS 上安装集群中的"创建 AWS 资源"。如果您需要在修改 AWS 资源前查看 ccoctl 工具创建的 JSON 文件，或者 ccoctl 工具用于创建 AWS 资源的进程自动满足您的机构要求时，这个选项可能很有用。

   2

   指定用于标记创建用于跟踪的任何云资源的名称。

   3

   指定在其中创建云资源的 AWS 区域。

   4

   指定包含组件 CredentialsRequest 对象文件的目录。

   5

   可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。

   6

   可选：默认情况下，ccoctl 实用程序将 OpenID Connect (OIDC) 配置文件存储在公共 S3 存储桶中，并使用 S3 URL 作为公共 OIDC 端点。要将 OIDC 配置存储在 IAM 身份提供程序通过公共 CloudFront 发行版 URL 访问的专用 S3 存储桶中，请使用 --create-private-s3-bucket 参数。

   例 2.2. Google Cloud Platform (GCP)

   $ ccoctl gcp create-all \
     --name=<name> \1
     --region=<gcp_region> \2
     --project=<gcp_project_id> \3
     --credentials-requests-dir=<path_to_credentials_requests_directory> \4
     --output-dir=<path_to_ccoctl_output_dir> 5

   1

   为用于跟踪的所有创建 GCP 资源指定用户定义的名称。

   2

   指定在其中创建云资源的 GCP 区域。

   3

   指定在其中创建云资源的 GCP 项目 ID。

   4

   指定包含 CredentialsRequest 清单文件的目录，以创建 GCP 服务帐户。

   5

   可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。

   例 2.3. IBM Cloud

   $ ccoctl ibmcloud create-service-id \
     --credentials-requests-dir=<path_to_credential_requests_directory> \1
     --name=<cluster_name> \2
     --output-dir=<installation_directory> \3
     --resource-group-name=<resource_group_name> 4

   1

   指定包含组件 CredentialsRequest 对象文件的目录。

   2

   指定 OpenShift Container Platform 集群的名称。

   3

   可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。

   4

   可选：指定用于限制访问策略的资源组的名称。

   例 2.4. Microsoft Azure

   $ ccoctl azure create-managed-identities \
     --name <azure_infra_name> \1
     --output-dir ./output_dir \
     --region <azure_region> \2
     --subscription-id <azure_subscription_id> \3
     --credentials-requests-dir <path_to_directory_for_credentials_requests> \
     --issuer-url "${OIDC_ISSUER_URL}" \4
     --dnszone-resource-group-name <azure_dns_zone_resourcegroup_name> \5
     --installation-resource-group-name "${AZURE_INSTALL_RG}" 6

   1

   name 参数的值用于创建 Azure 资源组。要使用现有的 Azure 资源组而不是创建新 Azure 资源组，请使用现有组名称指定 --oidc-resource-group-name 参数作为其值。

   2

   指定现有集群的区域。

   3

   指定现有集群的订阅 ID。

   4

   指定现有集群的 OIDC 签发者 URL。您可以运行以下命令来获取这个值：

   $ oc get authentication cluster \
     -o jsonpath \
     --template='{ .spec.serviceAccountIssuer }'

   5

   指定包含 DNS 区的资源组的名称。

   6

   指定 Azure 资源组名称。您可以运行以下命令来获取这个值：

   $ oc get infrastructure cluster \
     -o jsonpath \
     --template '{ .status.platformStatus.azure.resourceGroupName }'

   例 2.5. Nutanix

   $ ccoctl nutanix create-shared-secrets \
     --credentials-requests-dir=<path_to_credentials_requests_directory> \1
     --output-dir=<ccoctl_output_dir> \2
     --credentials-source-filepath=<path_to_credentials_file> 3

   1

   指定包含组件 CredentialsRequests 对象文件的目录路径。

   2

   可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。

   3

   可选：指定包含凭证数据 YAML 文件的目录。默认情况下，ccoctl 预期此文件位于 <home_directory>/.nutanix/credentials 中。

   对于每个 CredentialsRequest 对象，ccoctl 会创建所需的供应商资源和 OpenShift Container Platform 发行镜像中的每个 CredentialsRequest 对象中定义的权限策略。

2. 运行以下命令，将 secret 应用到集群：

   $ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

流程

1. 为新发行镜像添加的任何 CredentialsRequest 自定义资源创建 YAML 文件。secret 必须使用在 spec.secretRef 中为每个 CredentialsRequest 定义的命名空间和 secret 名称存储。

   例 2.6. AWS YAML 文件示例

   使用 secret 的 AWS CredentialsRequest 对象示例

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - effect: Allow
         action:
         - s3:CreateBucket
         - s3:DeleteBucket
         resource: "*"
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   AWS Secret 对象示例

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     aws_access_key_id: <base64_encoded_aws_access_key_id>
     aws_secret_access_key: <base64_encoded_aws_secret_access_key>

   例 2.7. Azure YAML 文件示例

   注意

   全局 Azure 和 Azure Stack Hub 使用相同的 CredentialsRequest 对象和 secret 格式。

   带有 secret 的 Azure CredentialsRequest 对象示例

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AzureProviderSpec
       roleBindings:
       - role: Contributor
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   Azure Secret 对象示例

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     azure_subscription_id: <base64_encoded_azure_subscription_id>
     azure_client_id: <base64_encoded_azure_client_id>
     azure_client_secret: <base64_encoded_azure_client_secret>
     azure_tenant_id: <base64_encoded_azure_tenant_id>
     azure_resource_prefix: <base64_encoded_azure_resource_prefix>
     azure_resourcegroup: <base64_encoded_azure_resourcegroup>
     azure_region: <base64_encoded_azure_region>

   例 2.8. GCP YAML 文件示例

   带有 secret 的 GCP CredentialsRequest 对象示例

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: GCPProviderSpec
         predefinedRoles:
         - roles/iam.securityReviewer
         - roles/iam.roleViewer
         skipServiceCheck: true
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   GCP Secret 对象示例

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     service_account.json: <base64_encoded_gcp_service_account_file>

2. 如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要求，请根据需要更新权限。

流程

1. 以具有 cluster-admin 角色的用户身份登录到集群中的 oc。

2. 运行以下命令，编辑 CloudCredential 资源，以在 metadata 字段中添加 upgradeable-to 注解：

   $ oc edit cloudcredential cluster

   要添加的文本

   ...
     metadata:
       annotations:
         cloudcredential.openshift.io/upgradeable-to: <version_number>
   ...

   其中 <version_number> 是您要升级到的版本，格式为 x.y.z。例如，OpenShift Container Platform 4.12.2 使用 4.12.2。

   添加可升级状态进行更改的注解后，可能需要几分钟时间。

验证

1. 在 Web 控制台的 Administrator 视角中，导航到 Administration → Cluster Settings。

2. 要查看 CCO 状态详情，请点击 Cluster Operators 列表中的 cloud-credential。

   • 如果 Conditions 部分中的 Upgradeable 状态为 False，请验证 upgradeable-to 注解没有拼写错误。
3. 当 Conditions 部分中的 Upgradeable 状态为 True 时，开始 OpenShift Container Platform 升级。

1. 镜像验证阶段
2. 构建验证阶段
3. 签名验证阶段

流程

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-

流程

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.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 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.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

流程

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

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

流程

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

   $ oc adm upgrade --include-not-recommended

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

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

   <.> <version> 是从上一个命令输出中获取的更新版本，它被支持但也存在已知问题或风险。

流程

1. 导航到 Administration → Cluster Settings，点 version。

2. 点击 YAML 选项卡，然后编辑 upstream 参数值：

   输出示例

     ...
     spec:
       clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
       upstream: '<update-server-url>' 1
     ...

   1

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

   默认 upstream 是 https://api.openshift.com/api/upgrades_info/v1/graph。

3. 点击 Save。

流程

1. 登陆到 OpenShift Container Platform Web 控制台。
2. 进入到 Compute → MachineHealthChecks。

3. 要暂停机器健康检查，请在每个 MachineHealthCheck 资源中添加 cluster.x-k8s.io/paused="" 注解。例如，要将注解添加到 machine-api-termination-handler 资源，请完成以下步骤：

   1. 点 machine-api-termination-handler 旁边的 Options 菜单 并点 Edit annotations。
   2. 在 Edit annotations 对话框中，点 Add more。
   3. 在 Key 和 Value 字段中，分别添加 cluster.x-k8s.io/paused 和 "" 值，然后点 Save。

流程

1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。

2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-4.17。

   重要

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

   注意

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

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

   • 如果 Update 状态 不是 Updates available，则无法升级集群。
   • Select channel 表示集群正在运行或正在更新的集群版本。

3. 选择要更新到的版本，然后单击 Save。

   输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。

   注意

   如果您要将集群升级到下一个次版本，例如从 4.10 升级到 4.11，请在部署依赖新功能的工作负载前确认您的节点已更新。任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。

4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。

   • 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
   • 如果没有可用的更新，请将 Channel 改为下一个次版本的 stable-*, eus-* 或 fast-* 频道，并更新至您在该频道中想要的版本。

   您可能需要执行一些过渡的更新，直到您到达您想要的版本。

流程

1. 在 Web 控制台中，点 Administration → Cluster settings 页面并查看 Details 选项卡的内容。

2. 您可以在 更新集群 模态的 Select new version 下拉列表中启用 Include versions with known issues 功能以使下拉列表中包括有条件的更新。

   注意

   如果选择了具有已知问题的版本，则会提供与版本相关的潜在风险的更多信息。

3. 查看通知详细描述了更新的潜在风险。

1. 根据 worker 池创建自定义机器配置池 (MCP)。

   注意

   您可以更改 MCP 中的 maxUnavailable 设置，以指定在任意给定时间可以更新的机器的百分比或数量。默认值为 1。

   警告

   对于 OpenShift Container Platform 中的所有机器配置池，maxUnavailable 的默认设置是 1。建议您不要更改这个值，且一次只更新一个 control plane 节点。对于 control plane 池，请不要将这个值改为 3。

2. 将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点，请向节点添加匹配的标签。该标签将节点与 MCP 相关联。

   重要

   不要从节点中删除默认 worker 标签。节点必须具有 role 标签才能在集群中正常工作。

3. 在更新过程中暂停您不想更新的 MCP。
4. 执行集群更新。更新过程更新没有暂停的 MCP，包括 control plane 节点。
5. 在更新的节点上测试应用程序，以确保它们按预期工作。
6. 取消暂停剩余的 MCP，等待池中的节点完成更新，并在这些节点上测试应用程序。重复此过程，直到所有 worker 节点都已更新。
7. 可选：从更新的节点中删除自定义标签并删除自定义 MCP。

流程

1. 运行以下命令列出集群中的 worker 节点：

   $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

   输出示例

   ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
   ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
   ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

2. 对于您要延迟的每个节点，运行以下命令为节点添加自定义标签：

   $ oc label node <node_name> node-role.kubernetes.io/<custom_label>=

   例如：

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

   输出示例

   node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

3. 创建新的 MCP：

   1. 创建 MCP YAML 文件：

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: workerpool-canary 1
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,workerpool-canary] 2
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/workerpool-canary: "" 3

      1

      为 MCP 指定名称。

      2

      指定 worker 和自定义 MCP 名称。

      3

      指定添加到此池中的自定义标签。

   2. 运行以下命令来创建 MachineConfigPool 对象：

      $ oc create -f <file_name>

      输出示例

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

4. 运行以下命令，查看集群中的 MCP 列表及其当前状态：

   $ oc get machineconfigpool

   输出示例

   NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
   workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
   worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

   创建新的机器配置池 workerpool-canary，机器计数中会显示您添加自定义标签的节点数量。worker MCP 机器数会减少相同的数字。更新机器数可能需要几分钟时间。在本例中，一个节点已从 worker MCP 移到 worker pool-canary MCP。

流程

1. 按照以下两个步骤所述，创建一个二级 MCP：

   1. 将以下配置文件保存为 machineConfigPool.yaml。

      machineConfigPool YAML 示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-perf
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,worker-perf]
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-perf: ""
      # ...

   2. 运行以下命令来创建新机器配置池：

      $ oc create -f machineConfigPool.yaml

      输出示例

      machineconfigpool.machineconfiguration.openshift.io/worker-perf created

2. 将一些机器添加到二级 MCP。以下示例将 worker 节点 worker-a、worker-b 和 worker-c 标记为 MCP worker-perf ：

   $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-b node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-c node-role.kubernetes.io/worker-perf=''

3. 为 MCP worker-perf 创建新的 MachineConfig，如以下两个步骤所述：

   1. 将以下 MachineConfig 示例保存为名为 new-machineconfig.yaml 的文件：

      MachineConfig YAML 示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: worker-perf
        name: 06-kdump-enable-worker-perf
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
            - enabled: true
              name: kdump.service
        kernelArguments:
          - crashkernel=512M
      # ...

   2. 运行以下命令来应用 MachineConfig ：

      $ oc create -f new-machineconfig.yaml

4. 创建新的 Canary MCP，并从您在上一步中创建的 MCP 添加机器。以下示例创建一个名为 worker-perf-canary 的 MCP，并添加您预先创建 worker-perf MCP 中的机器。

   1. 运行以下命令，标记 canary worker 节点 worker-a ：

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''

   2. 运行以下命令，从原始 MCP 中删除 Canary worker 节点 worker-a ：

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-

   3. 将以下文件保存为 machineConfigPool-Canary.yaml。

      machineConfigPool-Canary.yaml 文件示例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-perf-canary
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,worker-perf,worker-perf-canary] 1
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-perf-canary: ""

      1

      可选值。这个示例包括 worker-perf-canary 作为一个额外值。您可以使用此方法配置额外 MachineConfig 成员的值。

   4. 运行以下命令，创建新的 worker-perf-canary ：

      $ oc create -f machineConfigPool-Canary.yaml

      输出示例

      machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created

5. 检查 MachineConfig 是否继承在 worker-perf-canary 中。

   1. 运行以下命令验证没有 MCP 降级：

      $ oc get mcp

      输出示例

      NAME                  CONFIG                                                          UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master                rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac                True      False      False      3              3                   3                     0                      5d16h
      worker                rendered-worker-b9576d51e030413cfab12eb5b9841f34                True      False      False      0              0                   0                     0                      5d16h
      worker-perf          rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a          True      False      False      2              2                   2                     0                      56m
      worker-perf-canary   rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a   True      False      False      1              1                   1                     0                      44m

   2. 验证机器是否从 worker-perf 继承到 worker-perf-canary。

      $ oc get nodes

      输出示例

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      worker-a   Ready    worker,worker-perf-canary   5d15h   v1.27.13+e709aa5
      worker-b   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5
      worker-c   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5

   3. 运行以下命令，验证 worker-a 上是否启用了 kdump 服务：

      $ systemctl status kdump.service

      输出示例

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      kdump.service - Crash recovery kernel arming
           Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled)
           Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago
          Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
         Main PID: 4151139 (code=exited, status=0/SUCCESS)

   4. 运行以下命令验证 MCP 是否已更新了 crashkernel ：

      $ cat /proc/cmdline

      输出应包含更新的 crashekernel 值，例如：

      输出示例

      crashkernel=512M

6. 可选：如果对升级满意，您可以将 worker-a 返回到 worker-perf。

   1. 运行以下命令，将 worker-a 返回到 worker-perf ：

      $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   2. 运行以下命令，从 canary MCP 中删除 worker-a ：

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-

流程

1. 运行以下命令修补您要暂停的 MCP：

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

   例如：

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

   输出示例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

流程

1. 对您要取消暂停的 MCP 进行补丁：

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

   例如：

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

   输出示例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

2. 可选：使用以下选项之一检查更新的进度：

   1. 点 Administration → Cluster settings 从 web 控制台检查进度。

   2. 运行以下命令检查进度：

      $ oc get machineconfigpools

3. 在更新的节点上测试您的应用，以确保它们按预期工作。
4. 一次对任何其他暂停的 MCP 重复此过程。

流程

1. 对于自定义 MCP 中的每个节点，运行以下命令来从节点中删除自定义标签：

   $ oc label node <node_name> node-role.kubernetes.io/<custom_label>-

   例如：

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

   输出示例

   node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

   Machine Config Operator 将节点移回到原始 MCP，并将节点与 MCP 配置协调。

2. 要确保节点已从自定义 MCP 中删除，请运行以下命令来查看集群中的 MCP 列表及其当前状态：

   $ oc get mcp

   输出示例

   NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
   workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
   worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

   当节点从自定义 MCP 中删除并移回原始 MCP 时，可能需要几分钟时间来更新机器计数。在这个示例中，将一个节点从删除的 workerpool-canary MCP 移到 worker MCP。

3. 可选：运行以下命令来删除自定义 MCP：

   $ oc delete mcp <mcp_name>

流程

1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。

2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-4.17。

   重要

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

   注意

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

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

   • 如果 Update 状态 不是 Updates available，则无法升级集群。
   • Select channel 表示集群正在运行或正在更新的集群版本。

3. 选择要更新到的版本，然后单击 Save。

   输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。

   注意

   如果您要将集群升级到下一个次版本，例如从 4.10 升级到 4.11，请在部署依赖新功能的工作负载前确认您的节点已更新。任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。

4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。

   • 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
   • 如果没有可用的更新，请将 Channel 改为下一个次版本的 stable-*, eus-* 或 fast-* 频道，并更新至您在该频道中想要的版本。

   您可能需要执行一些过渡的更新，直到您到达您想要的版本。

   重要

   当您更新包含有 Red Hat Enterprise Linux (RHEL) worker 机器的集群时，这些 worker 会在更新过程中暂时不可用。当集群进入 NotReady 状态时，您需要针对每个 RHEL 机器运行升级 playbook 以完成更新。

流程

1. 停止并禁用主机上的防火墙：

   # systemctl disable --now firewalld.service

   注意

   默认情况下，使用 "Minimal" 安装选项的基础操作系统 RHEL 启用 firewalld 保护。在主机上启用了 firewalld 服务会阻止您访问 worker 上的 OpenShift Container Platform 日志。如果您希望继续访问 worker 上的 OpenShift Container Platform 日志，以后不要启用 firewalld。

2. 启用 OpenShift Container Platform 4.17 所需的仓库：

   1. 在运行 Ansible playbook 的机器上，更新所需的存储库：

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.17-for-rhel-8-x86_64-rpms

      重要

      自 OpenShift Container Platform 4.11 起，只有 RHEL 8 提供 Ansible playbook。如果 RHEL 7 系统用作 OpenShift Container Platform 4.10 Ansible playbook 的主机，您必须将 Ansible 主机升级到 RHEL 8，或者在 RHEL 8 系统中创建新的 Ansible 主机，并从旧的 Ansible 主机复制清单。

   2. 在运行 Ansible playbook 的机器上，更新 Ansible 软件包：

      # yum swap ansible ansible-core

   3. 在运行 Ansible playbook 的机器上，更新所需的软件包，包括 openshift-ansible：

      # yum update openshift-ansible openshift-clients

   4. 在每个 RHEL 计算节点上，更新所需的软件仓库：

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.17-for-rhel-8-x86_64-rpms

3. 更新 RHEL worker 机器：

   1. 检查 /<path>/inventory/hosts 中的 Ansible 清单文件并更新其内容，以便 RHEL 8 机器列在 [workers] 部分中，如下例所示：

      [all:vars]
      ansible_user=root
      #ansible_become=True
      
      openshift_kubeconfig_path="~/.kube/config"
      
      [workers]
      mycluster-rhel8-0.example.com
      mycluster-rhel8-1.example.com
      mycluster-rhel8-2.example.com
      mycluster-rhel8-3.example.com

   2. 进入 openshift-ansible 目录：

      $ cd /usr/share/ansible/openshift-ansible

   3. 运行 upgrade playbook:

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1

      1

      对于<path> ，指定您创建的Ansible库存文件的路径。

      注意

      upgrade playbook 仅升级 OpenShift Container Platform 软件包。它不会更新操作系统软件包。

4. 更新完所有 worker 后，确认所有集群节点已更新至新版本：

   # oc get node

   输出示例

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.30.3
   mycluster-control-plane-1   Ready                         master   145m   v1.30.3
   mycluster-control-plane-2   Ready                         master   145m   v1.30.3
   mycluster-rhel8-0           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-1           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-2           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-3           Ready                         worker   98m    v1.30.3

5. 可选：更新 upgrade playbook 没有更新的操作系统软件包。要更新不在 4.17 中的软件包，请使用以下命令：

   # yum update

   注意

   如果您使用安装 4.17 时使用的相同 RPM 存储库，则不需要排除 RPM 软件包。

流程

1. 运行以下命令，验证 Cluster Version Operator (CVO) 中的 RetrievedUpdates 条件是否为 True ：

   $ oc get clusterversion/version -o=jsonpath="{.status.conditions[?(.type=='RetrievedUpdates')].status}"

   如果 RetrievedUpates 条件为 False，您可以使用以下命令查找有关故障的补充信息：

   $ oc adm upgrade

   如需有关集群版本状况类型的更多信息，请参阅了解集群版本状况类型。

2. 如果条件 RetrievedUpdates 是 False，使用以下命令将频道改为 stable-<4.y> 或 fast-<4.y>：

   $ oc adm upgrade channel <channel>

   设置频道后，验证 RetrievedUpdates 是否为 True。

   有关频道的更多信息，请参阅了解更新频道和发行版本。

3. 使用以下命令迁移到多架构有效负载：

   $ oc adm upgrade --to-multi-arch

1. 检查系统状态：

   # bootupctl status

   x86_64的输出示例

   Component EFI
     Installed: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64
     Update: At latest version

   aarch64 的输出示例

   Component EFI
     Installed: grub2-efi-aa64-1:2.02-99.el8_4.1.aarch64,shim-aa64-15.4-2.el8_1.aarch64
     Update: At latest version

2. OpenShift Container Platform 集群最初安装在版本 4.4 及更早的版本中，需要明确的采用阶段。

   如果系统状态为 Adoptable，请执行采用：

   # bootupctl adopt-and-update

   输出示例

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

3. 如果有可用更新，请应用更新以便在下次重启时使更改生效：

   # bootupctl update

   输出示例

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

1. 创建一个 Butane 配置文件 99-worker-bootupctl-update.bu，包括 bootupctl-update.service systemd 单元的内容。

   注意

   有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。

   输出示例

   variant: openshift
   version: 4.17.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   systemd:
     units:
     - name: bootupctl-update.service
       enabled: true
       contents: |
         [Unit]
         Description=Bootupd automatic update
   
         [Service]
         ExecStart=/usr/bin/bootupctl update
         RemainAfterExit=yes
   
         [Install]
         WantedBy=multi-user.target

   1 2

   在 control plane 节点上，在这两个位置中将 master 替换为 worker。

2. 使用 Butane 生成 MachineConfig 对象文件 99-worker-bootupctl-update.yaml，其中包含要传送到节点的配置：

   $ butane 99-worker-bootupctl-update.bu -o 99-worker-bootupctl-update.yaml

3. 使用以下两种方式之一应用配置：

   • 如果集群还没有运行，在生成清单文件后，将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中，然后继续创建集群。

   • 如果集群已在运行，请应用该文件：

     $ oc apply -f ./99-worker-bootupctl-update.yaml

流程

1. 运行以下命令，将 OC_ENABLE_CMD_UPGRADE_STATUS 环境变量设置为 true ：

   $ export OC_ENABLE_CMD_UPGRADE_STATUS=true

2. 运行 oc adm upgrade status 命令：

   $ oc adm upgrade status

   例 4.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

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