Menu Close
Settings Close

Language and Page Formatting Options

升级

OpenShift Dedicated 4

升级 OpenShift Dedicated

摘要

本文档提供有关升级 OpenShift Dedicated 集群的信息。

第 1 章 准备将 OpenShift Dedicated 升级到 4.9

将 OpenShift Dedicated 集群升级到 OpenShift 4.9 需要您评估并迁移 API,因为 Kubernetes 的最新版本删除了大量 API。

在升级 OpenShift Dedicated 集群前,必须将所需工具更新为适当的版本。

1.1. 升级到 OpenShift 4.9 时管理员被确认

OpenShift Dedicated 4.9 使用 Kubernetes 1.22,它删除了大量已弃用的 v1beta1 API。

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

所有 OpenShift Dedicated 4.8 集群都需要此管理员确认才能升级到 OpenShift Dedicated 4.9。

1.2. 删除了 Kubernetes API

OpenShift Dedicated 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.3. 为删除的 API 评估集群

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

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

APIRemovedInNextReleaseInUse 警报告知您在集群中使用了 API。如果在集群中触发此警报,请查看警报;通过迁移清单和 API 客户端来清除警报,以使用新的 API 版本。您可以使用 APIRequestCount API 了解有关使用哪些 API 以及哪些工作负载正在使用删除 API 的更多信息。

1.3.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.3.3. 使用 APIRequestCount 来识别哪些工作负载正在使用删除的 API

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

先决条件

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

流程

  • 运行以下命令并检查 usernameuserAgent 字段,以帮助识别使用 API 的工作负载:

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

    例如:

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

    您还可以使用 -o jsonpathAPIRequestCount 资源中提取 username 值:

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

    输出示例

    user1
    user2
    app:serviceaccount:delta

1.4. 迁移已删除 API 实例

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

第 2 章 OpenShift Dedicated 集群升级

您可以调度自动或手动升级策略来更新 OpenShift Dedicated 集群的版本。升级 OpenShift Dedicated 集群可以通过 Red Hat OpenShift Cluster Manager 或 OpenShift Cluster Manager CLI 完成。

Red Hat Site Reliability Engineers (SRE)监控升级进度并补救遇到的问题。

2.1. 了解 OpenShift Dedicated 集群升级

当为 OpenShift Dedicated 集群提供升级时,您可以通过 Red Hat OpenShift Cluster Manager 或 OpenShift Cluster Manager CLI 升级到最新版本。您可以在现有集群或集群创建过程中设置升级策略,并且可以调度升级以自动或手动进行。

Red Hat Site Reliabilitys(SRE)将为您的 OpenShift Dedicated 集群提供策展的可用版本列表。对于每个集群,您可以查看可用版本的完整列表以及相应的发行注记。OpenShift Cluster Manager 将在最新支持的版本中启用集群的安装,您可以随时取消升级。

您还可以在升级过程中为 PodDisruptionBudget 保护的工作负载设置宽限期。在此宽限期后,任何不受从节点成功排空的 PodDisruptionBudget 保护的工作负载都会被强制删除。

注意

每个 OpenShift Dedicated 集群中的所有 Kubernetes 对象和 PV 作为 OpenShift Dedicated 服务的一部分备份。应用程序和应用程序数据备份不是 OpenShift Dedicated 服务的一部分。在调度升级前,请确保您有用于应用程序和应用程序数据的备份策略。

2.1.1. 重复升级

可计划在集群所有者或管理员指定的日期和时间上自动进行升级。每周进行升级,除非目前无法进行升级。

如果您为集群选择周期性更新,则必须提供管理员的确认。OpenShift Cluster Manager 不会为次版本启动 y-stream 更新,而不会收到管理员的确认。有关管理员确认的详情,请参阅 升级到 OpenShift 4.9 时管理员确认

注意

周期性升级策略是可选的,如果未设置,则升级策略会默认为单独的升级策略。

2.1.2. 个人升级

如果选择单独升级,则需要更新集群。如果您选择了一个需要批准的更新版本,则必须提供一个管理员的确认。有关管理员确认的详情,请参阅 升级到 OpenShift 4.9 时管理员确认

如果您的集群版本已过时,则会过渡到有限的支持状态。如需有关 OpenShift 生命周期策略的更多信息,请参阅 OpenShift Dedicated 更新生命周期

2.1.3. 升级通知

在 OpenShift Cluster Manager 控制台中,您可以在 Overview 选项卡中查看集群的历史记录。在 Cluster history 标题的 Cluster history 标题下,可以在服务日志中查看 Upgrade 状态。

每个状态更改也会触发对集群所有者和订阅的用户的电子邮件通知。您将收到以下事件的电子邮件通知:

  • 已调度升级。
  • 已启动升级。
  • 升级已完成。
  • 升级已被取消。
注意

对于周期性升级,您还会根据以下节奏在升级发生前收到电子邮件通知:

  • 2 周通知
  • 1 周通知
  • 1 天通知

其他资源

2.2. 为集群调度重复升级

您可以使用 OpenShift Cluster Manager 为 OpenShift Dedicated 集群调度 z-stream 补丁版本的重复、自动升级。根据上游更改,可能有时会没有更新。因此,没有针对这个星期的升级。

流程

  1. OpenShift Cluster Manager Hybrid Cloud Console 中,从集群列表中选择您的集群。
  2. Upgrade settings 选项卡访问升级 Operator。
  3. 要计划周期性升级,请选择 Recurring updates
  4. 提供管理员的确认信息,然后单击 批准并继续。OpenShift Cluster Manager 不会为次版本启动 y-stream 更新,而不会收到管理员的确认。
  5. 指定集群升级的当天以及您要升级的时间。
  6. 点击 Save
  7. 可选: 通过从下拉列表中选择指定的时间来为节点排空 设置宽限期。默认设置 1 小时 宽限期。
  8. 要编辑现有的周期性升级策略,请从 Upgrade Settings 选项卡中编辑首选的日期或开始时间。点击 Save
  9. 要取消周期性升级策略,请从 Upgrade Settings 选项卡中将升级方法切换到个人。点击 Save

Upgrade settings 选项卡中,Upgrade status 框表示已调度升级。下一个调度更新的日期和时间被列出。

2.3. 为集群调度单个升级

您可以使用 OpenShift Cluster Manager 一次手动升级 OpenShift Dedicated 集群。

流程

  1. OpenShift Cluster Manager Hybrid Cloud Console 中,从集群列表中选择您的集群。
  2. Upgrade settings 选项卡访问升级 Operator。您还可以在 Details 标题下点击集群版本旁的 更新 来从 Overview 选项卡中更新集群。
  3. 要计划单独升级,请选择 个人更新
  4. Update Status 框中点 Update。
  5. 选择您要升级集群的版本。推荐的集群升级会出现在 UI 中。要了解有关每个可用升级版本的更多信息,请点击 View 发行注记
  6. 如果您选择了一个需要批准的更新版本,请提供一个管理员的确认信息,并点击 Approve 继续
  7. 点击 Next
  8. 调度升级:

    • Upgrade now 在下一个小时内进行升级。
    • Schedule 不同的时间,并指定集群升级的日期和时间。
  9. 点击 Next
  10. 查看升级策略并点击 Confirm upgrade
  11. 在集群升级被调度时会显示确认。单击 Close
  12. 可选: 通过从下拉列表中选择指定的时间来为节点排空 设置宽限期。默认设置 1 小时 宽限期。

Overview 选项卡中,在集群版本旁的 UI 中没有调度升级。点 View details 查看升级详情。如果需要取消调度的升级,您可以从 View Details 弹出窗口中点击 Cancel this upgrade

Upgrade status 选项卡下的 Upgrade settings 选项卡中提供了相同的升级详情。如果需要取消调度的升级,可以从 Upgrade status 框中点 Cancel this upgrade

警告

如果发现了 OpenShift Dedicated 的 CVE 或其他关键问题,则所有集群都会在 48 小时内升级。当修复可用时,在 48 小时窗口关闭前,将会在您最新的首选开始时间自动升级集群。您还可以随时手动升级,然后再进行重复升级。