升级

OpenShift Dedicated 4

升级 OpenShift Dedicated

Red Hat OpenShift Documentation Team

摘要

本文档提供有关升级 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 集群的版本。可以通过 Red Hat OpenShift Cluster Manager 或 OpenShift Cluster Manager CLI 升级 OpenShift Dedicated 集群。

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

2.1. 了解 OpenShift Dedicated 集群升级

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

Red Hat Site Reliability 工程师 (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 标题下查看。

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

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

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

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

其他资源

2.2. 为集群调度重复升级

您可以使用 OpenShift Cluster Manager 为 OpenShift Dedicated 集群调度 z-stream 补丁版本的重复、自动升级。根据上游更改,可能不会发布更新。因此,在这周内不会进行升级。

流程

  1. OpenShift Cluster Manager 中,从集群列表中选择集群。
  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 中,从集群列表中选择集群。
  2. Upgrade settings 选项卡访问升级 Operator。您还可以使用 Overview 标签页更新您的集群,点 Details 标题下的集群版本旁的 Update
  3. 要计划单个升级,请选择 Individual updates
  4. Update Status 框中的 Update
  5. 选择您要升级集群的版本。推荐的集群升级会出现在 UI 中。要了解更多有关每个可用升级版本的信息,请点 View release notes
  6. 如果您选择了一个需要批准的更新版本,请提供一个管理员的确认信息,并点 Approve and continue
  7. Next
  8. 调度升级:

    • Upgrade now 在下一个小时内升级。
    • Schedule a different time 并指定您要集群升级的日期和时间。
  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

警告

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

法律通告

Copyright © 2024 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.