Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 3 章 升级 OpenShift AI 的要求

在升级 OpenShift AI 时，您必须完成以下任务。

检查 DataScienceCluster 对象中的组件

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

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

注意

在升级过程中，新组件不会自动添加到 DataScienceCluster 对象中。如果要使用新组件，必须手动编辑 DataScienceCluster 对象来添加组件条目。

迁移数据科学管道

在以前的版本中，OpenShift AI 中的数据科学管道基于 KubeFlow Pipelines v1。数据科学管道现在基于 KubeFlow Pipelines v2，它使用不同的工作流引擎。在 OpenShift AI 中默认启用和部署数据科学管道 2.0。

Data Science pipelines 1.0 资源不再受到 OpenShift AI 的支持或管理。无法再从仪表板或 KFP API 服务器部署、查看或编辑基于数据科学管道 1.0 的管道详情。

OpenShift AI 不会自动将现有数据科学管道 1.0 实例迁移到 2.0。在升级 OpenShift AI 前，您必须手动迁移现有的数据科学管道 1.0 实例。如需更多信息，请参阅 迁移到数据科学管道 2.0。

重要

Data Science pipelines 2.0 包含 Argo 工作流的安装。红帽不支持直接客户使用这个 Argo 工作流实例。

如果您升级到启用了数据科学管道的 OpenShift AI，并且集群中存在没有由数据科学管道安装的 Argo Workflows 实例，则不会升级 OpenShift AI 组件。要完成组件升级，请禁用数据科学管道或删除 Argo 工作流的独立实例。组件升级将自动完成。

地址 KServe 要求

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

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

地址 RAG 依赖项

如果您计划使用 Llama Stack 部署 Retrieval-Augmented Generation (RAG)工作负载，您必须满足以下要求：

更新与 OdhDashboardConfig 资源交互的工作流

在以前的版本中，集群管理员使用 OdhDashboardConfig 资源中的 groupsConfig 选项来管理可以访问 OpenShift AI 仪表板的 OpenShift 组（管理员和非管理员用户）。从 OpenShift AI 2.17 开始，此功能已移至 Auth 资源。如果您有与 OdhDashboardConfig 交互的工作流（如 GitOps 工作流），您必须更新它们以引用 Auth 资源。

Expand
表 3.1. 用户管理资源更新
 OpenShift AI 2.16 及更早版本OpenShift AI 2.17 及更新的版本

apiVersion

opendatahub.io/v1alpha

services.platform.opendatahub.io/v1alpha1

kind

OdhDashboardConfig

Auth

名称

odh-dashboard-config

auth

管理员组

spec.groupsConfig.adminGroups

spec.adminGroups

用户组

spec.groupsConfig.allowedGroups

spec.allowedGroups

将嵌入式 Kueue 过渡到 Red Hat build of Kueue

用于管理分布式工作负载的嵌入式 Kueue 组件已弃用。OpenShift AI 现在使用红帽构建的 Kue Operator 在分布式培训、工作台和模型为工作负载提供增强的工作负载调度。

为确保工作负载继续使用队列管理，您必须从嵌入式 Kueue 组件迁移到红帽构建的 Kueue Operator，这需要 OpenShift Container Platform 4.18 或更高版本。如需更多信息，请参阅 迁移到红帽构建的 Kue Operator。

更新嵌入式 Kueue

如果您还没有迁移到 Kueue Operator 构建，您必须更新嵌入的 Kueue 组件。

在 OpenShift AI 中，集群管理员使用 Kueue 为分布式工作负载配置配额管理。

当从 OpenShift AI 2.17 或更早版本升级时，MultiKue Custom Resource Definitions (CRD)的版本从 v1alpha1 改为 v1beta1。

但是，如果 kueue 组件被设置为 Managed，Red Hat OpenShift AI Operator 不会在升级过程中自动删除 v1alpha1 MultiKueue CRD。然后，Kueue 组件的部署会被阻断，如 default-dsc DataScienceCluster 自定义资源中所示，其中 kueReady 条件的值仍然设置为 False。

您可以按照以下方法解决这个问题：

注意

Red Hat OpenShift AI 目前不支持 MultiKueue 功能。如果您根据 MultiKueue CRD 创建任何资源，则在删除 CRD 时会删除这些资源。如果您不想丢失数据，请在删除 CRD 前创建备份。

  1. 登录 OpenShift 控制台。
  2. 在 Administrator 视角中，点 Administration CustomResourceDefinitions。
  3. 在搜索字段中，输入 multik。

  4. 更新 MultiKueueCluster CRD，如下所示：

    1. 点 CRD 名称，然后点 YAML 选项卡。

    2. 确保 metadata:labels 部分包含以下条目： 

      app.opendatahub.io/kueue: 'true'
      Copy to Clipboard Toggle word wrap
    3. 点击 Save。
  5. 重复上述步骤，以更新 MultiKueConfig CRD。

  6. 通过为每个 CRD 完成以下步骤来删除 MultiKueCluster 和 MultiKueConfig CRD：

    1. 点 Actions 菜单。
    2. 点 Delete CustomResourceDefinition。
    3. 点 Delete 以确认删除。

Red Hat OpenShift AI Operator 启动 Kueue Controller，Kueue 会自动创建 v1beta1 MultiKueue CRD。在 default-dsc DataScienceCluster 自定义资源中，ku eueReady 条件更改为 True。有关如何检查 kue-controller-manager- <pod-id> pod 是否正在运行 的详情，请参阅安装分布式工作负载组件。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部