第 1 章 升级 OpenShift AI Self-Managed 概述
作为集群管理员,您可以在断开连接的环境中为 Red Hat OpenShift AI Operator 配置自动或手动升级。断开连接的环境是一个网络受限网络,Operator Lifecycle Manager (OLM) 无法访问需要互联网连接的默认 Operator Hub 和镜像 registry。
有关在连接的环境中将 OpenShift AI 作为自我管理的软件升级的详情,请参考 升级 OpenShift AI Self-Managed。
在以前的版本中,OpenShift AI 中的数据科学管道基于 KubeFlow Pipelines v1。数据科学管道现在基于 KubeFlow Pipelines v2,它使用不同的工作流引擎。在 OpenShift AI 中默认启用和部署数据科学管道 2.0。
Data Science pipelines 1.0 资源不再受到 OpenShift AI 2.16 的支持或管理。升级到 OpenShift AI 2.16 后,无法再从仪表板或 KFP API 服务器部署、查看或编辑基于数据科学管道 1.0 的管道详情。如果您是当前数据科学管道用户,请不要升级到 OpenShift AI 2.16,直到您准备好迁移到数据科学管道 2.0。
OpenShift AI 不会自动将现有数据科学管道 1.0 实例迁移到 2.0。如果要升级到 OpenShift AI 2.16,您必须手动迁移现有的数据科学管道 1.0 实例并更新您的工作台。如需更多信息,请参阅 迁移到数据科学管道 2.0。
Data Science pipelines 2.0 包含 Argo 工作流的安装。OpenShift AI 不支持将这个 Argo 工作流安装的用户使用。要使用数据科学管道升级到 OpenShift AI 2.9 或更高版本,请确保集群中不存在单独的 Argo 工作流安装。
- 如果配置自动升级,当有新版本的 Red Hat OpenShift AI Operator 可用时,且更新了您的镜像 registry 内容,Operator Lifecycle Manager (OLM)将自动升级 Operator 的运行实例,而无需人为干预。
如果配置手动升级,当有新版本的 Red Hat OpenShift AI Operator 并更新您的镜像 registry 内容时,OLM 会创建一个更新请求。
集群管理员必须手动批准更新请求,才能将 Operator 更新至新版本。如需有关 批准待处理的 Operator 升级 的更多信息,请参阅手动批准待处理的 Operator 升级。
默认情况下,Red Hat OpenShift AI Operator 遵循一个后续更新过程。这意味着,如果当前版本和您要升级到的版本之间存在几个次版本,Operator Lifecycle Manager (OLM)会在将 Operator 升级到最终的目标版本前,将 Operator 升级到每个次版本。如果配置自动升级,OLM 会自动将 Operator 升级到最新的可用版本,而无需人为干预。如果配置手动升级,集群管理员必须手动批准当前版本和最终目标版本之间的每个后续更新。
有关 OpenShift AI Self-Managed 发行类型和支持的版本的详情,请查看 Red Hat OpenShift AI Self-Managed 生命周期 知识库文章。
- 在升级 OpenShift AI 之前,您应该完成升级 OpenShift AI 的要求。
- 在 OpenShift AI 中使用加速器前,您的实例必须有关联的加速器配置集。如果您的 OpenShift 实例具有加速器,则升级后会保留其加速器配置集。有关加速器的更多信息,请参阅使用加速器。
笔记本镜像会在升级过程中集成到镜像流中,然后出现在 OpenShift AI 仪表板中。
注意笔记本镜像由外部构建;它们是预先构建的镜像,执行每季度更改,并且不会随着每个 OpenShift AI 升级而改变。