升级

Red Hat OpenShift Service on AWS 4

了解 Red Hat OpenShift Service on AWS 的升级选项

Red Hat OpenShift Documentation Team

摘要

本文档提供有关升级 Red Hat OpenShift Service on AWS 集群的信息。

第 1 章 准备将 ROSA 升级到 4.9

将 Red Hat OpenShift Service on AWS 集群升级到 OpenShift 4.9 需要您评估并迁移您的 API，因为 Kubernetes 的最新版本删除了大量 API。

在升级 Red Hat OpenShift Service on AWS 集群前，必须将所需的工具升级到适当版本。

1.1. 升级到 OpenShift 4.9 的要求

要将使用 AWS 安全令牌服务 (STS) 的 Red Hat OpenShift Service on AWS (ROSA) 集群从版本 4.8 升级到 4.9，需要满足以下要求。

先决条件

  • 您已在安装主机上安装了最新的 AWS CLI。
  • 您已在安装主机上安装了 1.1.10 或更高版本的 ROSA CLI (rosa)。
  • 您已在工作站上安装了 OpenShift CLI (oc) 版本 4.9 或更高版本。
  • 您有更新 AWS 帐户范围的角色和策略所需的权限。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已更新了 AWS Identity and Access Management (IAM) 帐户范围内的角色和策略，包括 Operator 策略到版本 4.9。

1.1.1. 升级到 OpenShift 4.9 需要管理员的确认

Red Hat OpenShift Service on AWS 4.9 使用 Kubernetes 1.22，它删除了大量已弃用的 v1beta1 API。

Red Hat OpenShift Service on AWS 4.8.14 引入了一项要求，在将集群从 Red Hat OpenShift Service on AWS 4.8 升级到 4.9 前，管理员必须提供手动确认。这有助于防止升级到 Red Hat OpenShift Service on AWS 4.9 后出现问题，其中已删除的 API 仍在由运行或与集群交互的工作负载、工具或其他组件使用。管理员必须针对将要删除的任何 API 评估其集群，并迁移受影响的组件，以使用适当的新 API 版本。完成此操作后，管理员可以向管理员提供确认。

在升级到 Red Hat OpenShift Service on AWS 4.9 前，所有 Red Hat OpenShift Service on AWS 4.8 集群都需要这个管理员的确认。

1.1.2. 删除的 Kubernetes API

Red Hat OpenShift Service on AWS 4.9 使用 Kubernetes 1.22，它删除了以下已弃用的 v1beta1 API。您必须迁移清单和 API 客户端以使用 v1 API 版本。有关迁移已删除 API 的更多信息，请参阅 Kubernetes 文档。

表 1.1. v1beta1 API 从 Kubernetes 1.22 中删除

资源API主要变化

APIService

apiregistration.k8s.io/v1beta1

否

CertificateSigningRequest

certificates.k8s.io/v1beta1

是

ClusterRole

rbac.authorization.k8s.io/v1beta1

否

ClusterRoleBinding

rbac.authorization.k8s.io/v1beta1

否

CSIDriver

storage.k8s.io/v1beta1

否

CSINode

storage.k8s.io/v1beta1

否

CustomResourceDefinition

apiextensions.k8s.io/v1beta1

是

入口

extensions/v1beta1

是

入口

networking.k8s.io/v1beta1

是

IngressClass

networking.k8s.io/v1beta1

否

Lease

coordination.k8s.io/v1beta1

否

LocalSubjectAccessReview

authorization.k8s.io/v1beta1

是

MutatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

是

PriorityClass

scheduling.k8s.io/v1beta1

否

角色

rbac.authorization.k8s.io/v1beta1

否

RoleBinding

rbac.authorization.k8s.io/v1beta1

否

SelfSubjectAccessReview

authorization.k8s.io/v1beta1

是

StorageClass

storage.k8s.io/v1beta1

否

SubjectAccessReview

authorization.k8s.io/v1beta1

是

TokenReview

authentication.k8s.io/v1beta1

否

ValidatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

是

VolumeAttachment

storage.k8s.io/v1beta1

否

1.2. 为删除的 API 评估集群

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

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

APIRemovedInNextReleaseInUse 警报会告知您在集群中使用了已删除的 API。如果在集群中出现这个警报，请仔细查看警报；通过将清单和 API 客户端迁移到新版本的 API 来清除这个警报。您可以使用 APIRequestCount API 了解有关使用哪些 API 以及哪些工作负载正在使用删除 API 的更多信息。

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

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

先决条件

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

流程

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

    $ oc get apirequestcounts

    输出示例

    NAME                                        REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
cloudcredentials.v1.operator.openshift.io                      32                      111
ingresses.v1.networking.k8s.io                                 28                      110
ingresses.v1beta1.extensions                1.22               16                      66
ingresses.v1beta1.networking.k8s.io         1.22               0                       1
installplans.v1alpha1.operators.coreos.com                     93                      167
...

    注意

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

    • 在结果中会显示 system:serviceaccount:kube-system:generic-garbage-collector，因为它会遍历所有注册的 API 搜索要删除的资源。
    • system:kube-controller-manager 在结果中显示，因为它在强制配额的同时遍历所有资源进行计数。

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

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

    输出示例

    1.22    certificatesigningrequests.v1beta1.certificates.k8s.io
1.22    ingresses.v1beta1.extensions
1.22    ingresses.v1beta1.networking.k8s.io

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

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

先决条件

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

流程

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

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

    例如： 

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml

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

    $ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o jsonpath='{range ..username}{$}{"\n"}{end}' | sort | uniq

    输出示例

    user1
user2
app:serviceaccount:delta

1.3. 迁移已删除 API 实例

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

第 2 章 升级使用 STS 的 ROSA 集群

2.1. 生命周期策略和计划

要计划升级，请查看 Red Hat OpenShift Service on AWS 更新生命周期。生命周期页中包括了发行定义、支持和升级要求、安装策略信息和生命周期日期。

手动启动升级或自动调度升级。Red Hat Site Reliability 工程师 (SRE) 监控升级进度并解决遇到的问题。

2.2. 升级使用 STS 的 ROSA 集群

有两种方法可以升级使用 AWS 安全令牌服务 (STS) 的 Red Hat OpenShift Service on AWS (ROSA) 集群：

  • 通过 ROSA CLI 单独升级(rosa)
  • 通过 OpenShift Cluster Manager 控制台单独升级
注意

有关升级不使用 AWS 安全令牌服务 (STS) 的 ROSA 集群的步骤，请参阅升级 ROSA 集群。

2.2.1. 使用 ROSA CLI 升级

您可以使用 ROSA CLI (rosa)手动升级使用 AWS 安全令牌服务(STS)的 Red Hat OpenShift Service on AWS (ROSA)集群。

如果有新版本可用时，此方法将调度集群立即升级。

先决条件

  • 您已在安装主机上安装和配置了最新的 ROSA CLI。
  • 如果要将集群从 4.7 升级到 4.8，请将 AWS Identity and Access Management (IAM) 帐户范围角色和策略升级到版本 4.8。您还在 CloudCredential 自定义资源中更新了 cloudcredential.openshift.io/upgradeable-to 注解。

流程

  1. 要验证集群的当前版本，请输入以下命令： 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    将 <cluster_name|cluster_id> 替换为集群名称或集群的 ID。

  2. 要验证升级是否可用，请输入以下命令： 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    该命令返回一个集群可以升级的版本列表，包括推荐的版本。

  3. 要将集群升级到最新可用版本，请输入以下命令： 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>

    集群会被调度立即进行升级。此操作可能需要一小时或更长时间，具体取决于您的工作负载配置，如 pod 中断预算。

    升级完成后您将收到一封电子邮件。您还可以通过从 ROSA CLI 再次运行 rosa describe cluster 命令或查看 OpenShift Cluster Manager 控制台中的状态来检查状态。：!sts:

故障排除

2.2.2. 通过 OpenShift Cluster Manager 控制台调度单独的升级

您可以使用 OpenShift Cluster Manager 手工一次升级使用 AWS 安全令牌服务 (STS) 的 Red Hat OpenShift Service on AWS (ROSA) 集群。

先决条件

  • 如果要将集群从 4.7 升级到 4.8，请将 AWS Identity and Access Management (IAM) 帐户范围角色和策略升级到版本 4.8。您还在 CloudCredential 自定义资源中更新了 cloudcredential.openshift.io/upgradeable-to 注解。如需更多信息，请参阅准备从 4.7 升级到 4.8。

流程

  1. 登录到 OpenShift Cluster Manager Hybrid Cloud Console。
  2. 选择要升级的集群。
  3. 点 Settings 选项卡。
  4. 在 Update 策略框中，选择 单个更新。
  5. 选择您要升级集群的版本。推荐的集群升级会出现在 UI 中。

  6. 如果您选择了一个需要批准的更新版本，请提供一个管理员的确认信息，并点 Approve and continue。

    有关管理员确认的详情，请参阅升级到 OpenShift 4.9 时的管理员确认。

  7. 在节点排空窗格中，从列表中选择一个宽限期间隔。宽限期可让节点在强制 pod 驱除前安全排空。默认值为 1 小时。
  8. 在 Update strategy 窗格中，点 Save 以应用您的更新策略。

  9. 在 Update status 窗格中，查看更新可用信息，然后点更新。

    注意

    只有在升级可用时才启用更新按钮。

  10. 在 Select version 对话框中，选择一个目标升级版本并点 Next。

  11. 在 Schedule update 对话框中，调度集群升级。

    • 要在一小时内升级，请选择 Update now 并点下一步。
    • 要稍后升级，请选择 Schedule a different time 并为升级设置时间和日期。点 Next 进入确认对话框。

  12. 检查版本和调度概述后，选择 Confirm update。

    为集群计划升级到目标版本。根据所选升级计划和工作负载配置（如 pod 中断预算），这个操作可能需要一小时或更长时间。

    状态显示在 Update status 窗格中。

故障排除

第 3 章 升级 ROSA 集群

3.1. 生命周期策略和计划

要计划升级，请查看 Red Hat OpenShift Service on AWS 更新生命周期。生命周期页中包括了发行定义、支持和升级要求、安装策略信息和生命周期日期。

手动启动升级或自动调度升级。Red Hat Site Reliability 工程师 (SRE) 监控升级进度并解决遇到的问题。

3.2. 升级 ROSA 集群

在 AWS(ROSA)集群上升级 Red Hat OpenShift Service 的方法有三种：

注意

有关升级使用 AWS 安全令牌服务 (STS) 的 ROSA 集群的步骤，请参阅升级使用 STS 的 ROSA 集群。

注意

当遵循调度的升级策略时，在升级过程开始可能会有一个小时或更长时间的延迟，即使它被调度为立即升级也是如此。另外，升级的持续时间可能会因工作负载配置而异。

3.2.1. 使用 ROSA CLI 升级

您可以使用 ROSA CLI (rosa)手动升级 Red Hat OpenShift Service on AWS (ROSA)集群。

如果有新版本可用时，此方法将调度集群立即升级。

先决条件

  • 您已在安装主机上安装和配置了最新的 ROSA CLI。

流程

  1. 要验证集群的当前版本，请输入以下命令： 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    将 <cluster_name|cluster_id> 替换为集群名称或集群的 ID。

  2. 要验证升级是否可用，请输入以下命令： 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    该命令返回一个集群可以升级的版本列表，包括推荐的版本。

  3. 要将集群升级到最新可用版本，请输入以下命令： 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>

    集群会被调度立即进行升级。此操作可能需要一小时或更长时间，具体取决于您的工作负载配置，如 pod 中断预算。

    升级完成后您将收到一封电子邮件。您还可以通过从 ROSA CLI 再次运行 rosa describe cluster 命令或查看 OpenShift Cluster Manager 控制台中的状态来检查状态。

故障排除

3.2.2. 通过 OpenShift Cluster Manager 控制台调度单独的升级

您可以使用 OpenShift Cluster Manager 调度手工一次升级 Red Hat OpenShift Service on AWS (ROSA) 集群。

流程

  1. 登录到 OpenShift Cluster Manager Hybrid Cloud Console。
  2. 选择要升级的集群。
  3. 点 Settings 选项卡。
  4. 在 Update 策略框中，选择 单个更新。
  5. 选择您要升级集群的版本。推荐的集群升级会出现在 UI 中。

  6. 如果您选择了一个需要批准的更新版本，请提供一个管理员的确认信息，并点 Approve and continue。

    有关管理员确认的详情，请参阅升级到 OpenShift 4.9 时的管理员确认。

  7. 在节点排空窗格中，从列表中选择一个宽限期间隔。宽限期可让节点在强制 pod 驱除前安全排空。默认值为 1 小时。
  8. 在 Update strategy 窗格中，点 Save 以应用您的更新策略。

  9. 在 Update status 窗格中，查看更新可用信息，然后点更新。

    注意

    只有在升级可用时才启用更新按钮。

  10. 在 Select version 对话框中，选择一个目标升级版本并点 Next。

  11. 在 Schedule update 对话框中，调度集群升级。

    • 要在一小时内升级，请选择 Update now 并点下一步。
    • 要稍后升级，请选择 Schedule a different time 并为升级设置时间和日期。点 Next 进入确认对话框。

  12. 检查版本和调度概述后，选择 Confirm update。

    为集群计划升级到目标版本。根据所选升级计划和工作负载配置（如 pod 中断预算），这个操作可能需要一小时或更长时间。

    状态显示在 Update status 窗格中。

故障排除

3.2.3. 为集群调度重复升级

您可以通过 OpenShift Cluster Manager 控制台，为 Red Hat OpenShift Service on AWS 调度定期、自动升级 z-stream 补丁版本。

流程

  1. 登录到 OpenShift Cluster Manager Hybrid Cloud Console。
  2. 选择要升级的集群。
  3. 点 Settings 选项卡。
  4. 在 Update strategy 窗格中，选择 Recurring updates。
  5. 当有更新可用时，为升级选择星期中的以天以及开始的时间。

  6. 提供管理员的确认信息，然后点批准并继续。在没有收到管理员确认的情况下，OpenShift Cluster Manager 不会为次版本启动 y-stream 更新。

    有关管理员确认的详情，请参阅升级到 OpenShift 4.9 时的管理员确认。

  7. 在节点排空窗格中，从列表中选择一个宽限期间隔。宽限期可让节点在强制 pod 驱除前安全排空。默认值为 1 小时。

  8. 在 Update strategy 窗格中，点 Save 以应用您的更新策略。

    当升级可用时，会在首选的天和开始的时间自动应用到集群。

第 4 章 使用 HCP 升级 ROSA

4.1. 生命周期策略和计划

要计划升级，请查看 Red Hat OpenShift Service on AWS 更新生命周期。生命周期页中包括了发行定义、支持和升级要求、安装策略信息和生命周期日期。

您可以手动升级集群。Red Hat Site Reliability 工程师 (SRE) 监控升级进度并解决遇到的问题。

4.2. 升级 ROSA 集群

您可以使用 Red Hat OpenShift Service on AWS (ROSA) CLI, rosa，使用托管 control plane (HCP)集群升级 Red Hat OpenShift Service on AWS (ROSA)集群。

注意

当遵循调度的升级策略时，在升级过程开始前可能会有不超过 30 分钟的延迟，即使它是一个立即升级。另外，升级的持续时间可能会因工作负载配置和机器池升级(worker 节点的数量)而有所不同。

4.2.1. 使用 ROSA CLI 升级

您可以使用 ROSA CLI (rosa)手动升级 Red Hat OpenShift Service on AWS (ROSA)集群。

如果有新版本可用时，此方法将调度集群立即升级。

先决条件

  • 您已在安装主机上安装和配置了最新的 ROSA CLI。

流程

  1. 要验证集群的当前版本，请输入以下命令： 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id> 1
    1
    将 <cluster_name|cluster_id> 替换为集群名称或集群的 ID。

  2. 要验证升级是否可用，请输入以下命令： 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>

    该命令返回一个集群可以升级的版本列表，包括推荐的版本。

  3. 要将集群升级到最新可用版本，请输入以下命令： 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id> --control-plane

    集群会被调度立即进行升级。此操作可能需要一小时或更长时间，具体取决于您的工作负载配置，如 pod 中断预算。

    升级完成后您将收到一封电子邮件。您还可以通过从 ROSA CLI 再次运行 rosa describe cluster 命令或查看 OpenShift Cluster Manager 控制台中的状态来检查状态。

故障排除

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.