升级 OpenShift AI 云服务

Red Hat OpenShift AI Cloud Service 1

在 OpenShift Dedicated 或 Red Hat OpenShift Service on AWS (ROSA)集群上升级 OpenShift AI

摘要

在 OpenShift Dedicated 或 Red Hat OpenShift Service on AWS (ROSA)集群上升级 OpenShift AI。

前言

作为集群管理员,您可以配置 OpenShift AI Operator 自动或手动升级。

第 1 章 升级 OpenShift AI 概述

当新版本或版本可用时,Red Hat OpenShift AI 会自动更新。目前,不需要管理员触发进程。

当出现 OpenShift AI 升级时,您应该 完成升级 OpenShift AI 的要求

备注:

  • 如果升级来自 OpenShift AI 版本 1 (以前为 OpenShift Data Science),请按照在 Red Hat OpenShift AI (OpenShift Data Science)版本 1 中清除未使用资源 的指南进行操作。
  • 在 OpenShift AI 中使用加速器前,您的实例必须具有关联的加速器配置文件。如果您的 OpenShift 集群实例有一个加速器,则升级后会保留其加速器配置集。有关加速器的更多信息,请参阅使用加速器
  • 笔记本镜像在升级过程中集成到镜像流中,然后出现在 OpenShift AI 仪表板中。笔记本镜像会在外部构建;它们是预先构建的镜像,这些镜像会每季度更改,且不会随每个 OpenShift AI 升级而改变。
重要

使用 DSP 2.0 升级到 OpenShift AI 后,使用 DSP 1.0 创建的管道将继续运行,但 OpenShift AI 仪表板无法访问。我们建议当前的 DSP 用户不要升级到带有 DSP 2.0 的 OpenShift AI,直到您准备好迁移到新的管道解决方案。Data Science Pipelines (DSP) 2.0 包含 Argo 工作流的安装。OpenShift AI 不支持直接客户使用此 Argo 工作流安装。要使用 DSP 2.0 升级到 OpenShift AI,请确保集群中不存在单独的 Argo 工作流安装。

第 2 章 为 OpenShift AI 配置升级策略

作为集群管理员,您可以为 Red Hat OpenShift AI Operator 配置自动或手动升级策略。

重要

默认情况下,Red Hat OpenShift AI Operator 会遵循一个连续的更新过程。这意味着,如果当前版本和您要升级到的版本之间有多个版本,Operator Lifecycle Manager (OLM)会在将其升级到最终目标版本前将 Operator 升级到每个中间版本。如果您配置自动升级,OLM 会自动将 Operator 升级到 最新的可用版本,而无需人为干预。如果配置手动升级,集群管理员必须手动批准当前版本和最终目标版本之间的每个连续更新。

有关支持的版本的详情,请查看 Red Hat OpenShift AI 生命周期

先决条件

  • 有 OpenShift 集群的集群管理员特权。
  • 安装了 Red Hat OpenShift AI Operator。

流程

  1. 以集群管理员身份登录 OpenShift 集群 Web 控制台。
  2. Administrator 视角中,在左侧菜单中选择 OperatorsInstalled Operators
  3. Red Hat OpenShift AI Operator。
  4. Subscription 标签页。
  5. Update approval 下,点铅笔图标并选择以下更新策略之一:

    • 自动 :在有新更新可用时即可安装新的更新。
    • 手动 :集群管理员必须在开始安装前批准任何新的更新。
  6. 点击 Save

其他资源

第 3 章 升级 OpenShift AI 的要求

本节介绍升级 OpenShift AI 时应完成的任务。

检查 DataScienceCluster 对象中的组件

升级 Red Hat OpenShift AI 时,升级过程会自动使用之前 DataScienceCluster 对象中的值。

升级后,您应该检查 DataScienceCluster 对象,并可以选择更新任何组件的状态,如使用 Web 控制台更新 Red Hat OpenShift AI 组件的安装状态 中所述。

重新创建现有管道运行

当您升级到更新的版本时,在之前的版本中创建的任何现有管道运行都会继续引用之前版本的镜像(如预期)。

您必须删除管道运行(而不是管道)并创建新的管道运行。您在更新版本中创建的管道运行可以正确地引用该镜像。

如需有关管道运行的更多信息,请参阅管理管道运行

升级到 Data Science Pipelines (DSP) 2.0

在以前的版本中,OpenShift AI 中的数据科学管道基于 KubeFlow Pipelines v1。从 OpenShift AI 的仪表板中,无法再部署、查看或编辑基于 Data Science Pipelines (DSP) 1.0 的管道详情。

DSP 2.0 包含 Argo 工作流的安装。OpenShift AI 不支持直接客户使用此 Argo 工作流安装。要使用 DSP 2.0 安装或升级到 OpenShift AI,请确保集群中没有现有的 Argo 工作流安装。

如果要在升级 OpenShift AI 后使用带有 DSP 2.0 的现有管道和工作台,您必须更新工作台以使用 2024.1 笔记本镜像版本,然后手动将管道从 DSP 1.0 迁移到 2.0。如需更多信息,请参阅 升级到 DSP 2.0

地址 KServe 要求

对于 KServe 组件,由单一模型服务平台用来服务大型模型,您必须满足以下要求:

  • 要完全安装和使用 KServe,还必须为 Red Hat OpenShift Serverless 和 Red Hat OpenShift Service Mesh 安装 Operator 并执行额外的配置。如需更多信息,请参阅 Serving 大模型
  • 如果要为单模式服务平台添加授权供应商,您必须安装 Red Hat - Authorino Operator。如需更多信息,请参阅 为单模式服务平台添加授权供应商

第 4 章 从 Red Hat OpenShift AI (OpenShift Data Science)的版本 1 中清理未使用的资源

OpenShift AI 版本 1 (以前称为 OpenShift Data Science)为 OpenShift AI 的各种组件创建了一组 Kubeflow 部署定义(即 KfDef)自定义资源实例。当您升级到 2 版本时,这些资源将不再使用,需要从集群中移除。以下流程演示了如何使用 OpenShift 命令行界面(CLI)和 Web 控制台从集群中删除未使用的 KfDef 实例。

4.1. 使用 CLI 删除未使用的资源

以下流程演示了如何使用 OpenShift 命令行界面(CLI)从 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中删除未使用的 KfDef 实例。从版本 1 升级到 OpenShift AI 版本 2 后,这些资源将变得未使用。

先决条件

  • 您已从版本 1 升级到 OpenShift AI 版本 2。
  • 有 OpenShift 集群的集群管理员特权。

流程

  1. 打开一个新的终端窗口。
  2. 在 OpenShift 命令行界面(CLI)中,以集群管理员身份登录到 OpenShift 集群,如下例所示:

    $ oc login <openshift_cluster_url> -u system:admin
  3. 删除 redhat-ods-applications 项目中存在的任何 KfDef 实例。

    $ oc delete kfdef --all -n redhat-ods-applications --ignore-not-found || true

    对于任何已删除的 KfDef 实例,输出类似以下示例:

    kfdef.kfdef.apps.kubeflow.org "rhods-dashboard" deleted
  4. 输入以下命令删除 redhat-ods-monitoringrhods-notebooks 项目中任何 KfDef 实例:

    $ oc delete kfdef --all -n redhat-ods-monitoring --ignore-not-found || true
    $ oc delete kfdef --all -n rhods-notebooks --ignore-not-found || true

验证

  • 检查所有 KfDef 实例是否已从 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中删除。

    $ oc get kfdef --all-namespaces

    验证您没有看到 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中列出的 KfDef 实例。

4.2. 使用 Web 控制台删除未使用的资源

以下流程演示了如何使用 OpenShift Web 控制台从 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中删除未使用的 KfDef 实例。从版本 1 升级到 OpenShift AI 版本 2 后,这些资源将变得未使用。

先决条件

  • 您已从版本 1 升级到 OpenShift AI 版本 2。
  • 有 OpenShift 集群的集群管理员特权。

流程

  1. 以集群管理员身份登录 OpenShift Web 控制台。
  2. 在 Web 控制台中,点 AdministrationCustomResourceDefinitions
  3. CustomResourceDefinitions 页面中,点 KfDef 自定义资源定义(CRD)。
  4. Instances 选项卡。

    页面中显示集群中的所有 KfDef 实例。

  5. 记录 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中存在的任何 KfDef 实例。这些是在此流程的其余部分中清理的项目。
  6. 要从 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中删除 KfDef 实例,点实例旁的操作菜单(HBAC),从列表中选择 Delete KfDef
  7. 若要确认删除实例,请单击 Delete
  8. 重复前面的步骤,以删除您在 redhat-ods-applicationsredhat-ods-monitoringrhods-notebooks 项目中看到的所有剩余的 KfDef 实例。

第 5 章 使用 Web 控制台更新 Red Hat OpenShift AI 组件的安装状态

以下流程演示了如何使用 OpenShift Web 控制台更新 OpenShift 集群中 Red Hat OpenShift AI 组件的安装状态。

重要

当 OpenShift AI 版本从以前的次版本升级时,升级过程会使用以前的 DataScienceCluster 对象中的设置。

以下流程描述了如何编辑 DataScienceCluster 对象:

  • 更改现有 Red Hat OpenShift AI 组件的安装状态
  • 在以前的 OpenShift AI 版本中没有可用的 DataScienceCluster 对象添加额外的组件。

先决条件

  • Red Hat OpenShift AI 作为 Red Hat OpenShift 集群的附加组件安装。
  • 有 OpenShift 集群的集群管理员特权。

流程

  1. 以集群管理员身份登录 OpenShift Web 控制台。
  2. 在 Web 控制台中,点 OperatorsInstalled Operators,然后点 Red Hat OpenShift AI Operator。
  3. Data Science Cluster 选项卡。
  4. DataScienceClusters 页面中,点 默认 对象。
  5. YAML 标签。

    此时会打开嵌入的 YAML 编辑器,显示 DataScienceCluster 对象的自定义资源(CR)文件。

  6. 在 CR 的 spec.components 部分中,对于所示的每个 OpenShift AI 组件,将 managementState 字段的值设置为 ManagedRemoved。这些值定义如下:

    注意

    如果组件显示 CR 的 spec.components 部分中的 component-name: {} 格式,则不会安装该组件。

    受管
    Operator 会主动管理组件,安装它,并尝试保持其活跃。只有在组件安全时,Operator 才会升级组件。
    删除
    Operator 会主动管理组件,但不安装它。如果组件已安装,Operator 将尝试将其删除。
    重要
    • 要了解如何安装 KServe 组件,该组件供单模式服务平台用于服务大型模型,请参阅 Serving 大模型
    • 如果 CR 文件中还不存在它们,您可以通过添加 codeflare、ray、ray 并将组件的 spec.components 部分的 managementState 字段设置为 Managed 来安装 CodeFlare、KubeRay 和 Kueue 组件。
    • 要了解如何配置使用 CodeFlare、KubeRay 和 Kueue 组件 的分布式工作负载功能,请参阅配置分布式工作负载
  7. 点击 Save

    对于您更新的任何组件,OpenShift AI 会启动一个推出影响所有 Pod 来使用更新的镜像。

验证

  • 确认每个组件都有一个正在运行的 pod:

    1. 在 OpenShift Web 控制台中,点击 WorkloadsPods
    2. 在页面顶部的 Project 列表中,选择 redhat-ods-applications
    3. 在 applications 命名空间中,确认您安装的每个 OpenShift AI 组件都有运行 pod。
  • 确认所有安装的组件的状态:

    1. 在 OpenShift Web 控制台中,点 OperatorsInstalled Operators
    2. 点 Red Hat OpenShift AI Operator。
    3. 单击 Data Science Cluster 选项卡,再选择名为 default-dscDataScienceCluster 对象。
    4. 选择 YAML 选项卡。
    5. installedComponents 部分中,确认您安装的组件的状态为 true

      注意

      如果组件显示 CR 的 spec.components 部分中的 component-name: {} 格式,则不会安装该组件。

第 6 章 升级后添加 CA 捆绑包

Red Hat OpenShift AI 1 支持使用自签名证书。如果您已经从 OpenShift AI 2.7 或更早版本升级,您可以在集群中的 OpenShift AI deployments 和 Data Science 项目中添加自签名证书。

将证书颁发机构(CA)捆绑包添加到 OpenShift AI 中有两种方法。您可以使用以下任一方法:

  • 对于依赖自签名证书的 OpenShift 集群,您可以将这些自签名证书添加到集群范围的证书颁发机构(CA)捆绑包(ca-bundle.crt),并使用 Red Hat OpenShift AI 中的 CA 捆绑包。
  • 您可以在与集群范围捆绑包分开的自定义 CA 捆绑包中使用自签名证书(odh-ca-bundle.crt)。

如需更多信息,请参阅使用证书

先决条件

  • 您有 admin 访问权限,访问 OpenShift 集群中的 DSCInitialization 资源。
  • CLI 入门 中所述,已安装 OpenShift 命令行界面(oc)。
  • 您已升级了 Red Hat OpenShift AI。如果您在新的 Red Hat OpenShift AI 安装中工作,请参阅 添加 CA 捆绑包

流程

  1. 以集群管理员身份登录 OpenShift。
  2. OperatorsInstalled Operators,然后点 Red Hat OpenShift AI Operator。
  3. DSC 初始化选项卡。
  4. default-dsci 对象。
  5. YAML 标签。
  6. spec 部分添加以下内容,将 managementState 字段设置为 Managed

    spec:
      trustedCABundle:
        managementState: Managed
        customCABundle: ""
  7. 如果要使用添加到集群范围 CA 捆绑包中的自签名证书,以集群管理员身份登录到 OpenShift,并按照 在安装过程中配置集群范围代理 中所述的步骤进行操作。
  8. 如果要在与集群范围捆绑包分开的自定义 CA 捆绑包中使用自签名证书,请按照以下步骤执行:

    1. 将自定义证书添加到 default-dsci 对象的 customCABundle 字段中,如下例所示:

      spec:
        trustedCABundle:
          managementState: Managed
          customCABundle: |
            -----BEGIN CERTIFICATE-----
            examplebundle123
            -----END CERTIFICATE-----
    2. 点击 Save

      Red Hat OpenShift AI Operator 创建一个 odh-trusted-ca-bundle ConfigMap,其中包含所有新的和现有非保留命名空间中的证书。

验证

  • 如果使用集群范围的 CA 捆绑包,请运行以下命令验证所有非保留命名空间是否包含 odh-trusted-ca-bundle ConfigMap:

    $ oc get configmaps --all-namespaces -l app.kubernetes.io/part-of=opendatahub-operator | grep odh-trusted-ca-bundle
  • 如果您使用自定义 CA 捆绑包,请运行以下命令来验证非保留命名空间是否包含 odh-trusted-ca-bundle ConfigMap,并且 ConfigMap 包含您的 customCABundle 值。在以下命令中,example-namespace 是非保留的命名空间,examplebundle123 是 customCABundle 值。

    $ oc get configmap odh-trusted-ca-bundle -n example-namespace -o yaml | grep examplebundle123

法律通告

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.