#升级 Alauda AI

本文档描述了从 Alauda AI 2.3.x 部署模型迁移到 Alauda AI 2.8.x 部署模型的过程。开始之前，请先通读完整的操作步骤。此次升级会变更若干组件的部署形式，其中一些组件需要执行迁移，而不是原地升级。

#准备升级软件包

在开始升级之前，请上传 Alauda AI 2.8.x operator 软件包以及所有必需的依赖软件包。将软件包上传到对应组件将运行所在的集群。关于公共软件包下载、violet 配置和上传操作，请参见 Upload Packages。

所需的软件包集合取决于现有环境中启用的功能。对于 Alauda AI 2.8.x 环境，至少请准备以下软件包：

准确的软件包文件名和版本随 Alauda AI 2.8.x 发布包提供。不要使用 Alauda AI 2.3.x 的软件包进行替代。

#上传 operator 软件包

公共软件包指南包含 violet push 命令、外部 registry 选项以及多软件包上传示例。请使用 Upload Packages 中的方法，结合 Alauda AI 2.8.x 发布包提供的文件名和目标集群信息上传各个软件包。

#升级前操作

在升级 Alauda AI 之前，请完成以下操作。

#保留现有资源

查看每个组件的迁移要求，并保留迁移过程中必须继续存在的资源。此升级中的组件设计为保留其数据；在可行的情况下，请保持数据原位，而不要重新创建。至少需要保留并记录以下内容：

• AmlCluster 资源及其当前 YAML 配置。
• 由 Workbench、MLflow、LWS、KServe 及其他已启用组件管理的自定义资源。
• Workspaces、WorkspaceKind 资源、aml-workbench-config ConfigMap 和用户 PVC。
• MLflow 元数据和制品存储配置。
• 推理服务配置和模型存储配置。
• 任何组件特定的 Secret、ConfigMap、RoleBinding 和授权策略。

在卸载旧的部署形式之前，请使用对应组件的备份说明。例如，Workbench 升级指南 会备份 Workbench 资源，并要求保留用户 PVC。

#检查目标集群

确认以下事项：

1. 目标集群运行正常，并且有足够的容量容纳新的 operators 及其 operands。
2. 目标集群可以从已配置的 registry 拉取镜像。
3. 所需的 StorageClass 和 PersistentVolume 可用。
4. 平台管理员凭据可以通过 OperatorHub 上传软件包并安装 Operator。
5. 可以使用 kubectl 访问 global 集群，以执行下面描述的全局迁移步骤。

#移除 Cluster Plugins

Alauda AI 2.8.x 将多个组件从 Cluster Plugin 形态改为 Operator 形态。这些部署形式不支持原地升级。在升级 Alauda AI 之前，请移除现有环境中已安装组件的旧版 Cluster Plugin：

• Alauda AI Essentials，位于 global 集群。
• Alauda Build of LeaderWorkerSet，位于目标集群。
• Alauda AI Workbench，位于目标集群。
• MLflow，位于目标集群。

请按以下通用步骤操作：

1. 记录已安装组件的现有自定义资源和配置。
2. 保留相关用户数据，包括 Workbench PVC、MLflow 数据库和制品，以及由 LeaderWorkerSet 管理的工作负载。
3. 在 Administrator > Marketplace > Cluster Plugins 中，选择相应集群：
   • 选择 global 集群，并卸载 Alauda AI Essentials（如果已安装）。
   • 选择目标集群，并卸载已安装的 Alauda Build of LeaderWorkerSet、Alauda AI Workbench 和 MLflow Cluster Plugin。
4. 除非相关组件的迁移步骤明确要求，否则不要删除已保留的 PVC、数据库、对象存储制品或自定义资源。
5. 在移除旧的 Cluster Plugin 之后，通过 Alauda AI 2.8.x 部署模型启用替代组件。升级后的 AmlCluster 会在 lws.managementState 为 Managed 时安装并协调 Alauda Build of LeaderWorkerSet。关于 Alauda AI Workbench 和 MLflow，请按照其组件特定文档安装替代 Operator 并创建对应的自定义资源。

现有的集群级 AmlCluster 资源 default 负责控制 Alauda AI 的部署配置。升级 Alauda AI 后，请使用该资源配置由 Alauda AI 管理的组件，包括 Alauda Build of LeaderWorkerSet。作为独立 Operator 提供的组件（例如 Workbench 和 MLflow）则通过各自的 Operator 自定义资源进行部署和配置。

关于 Workbench 特定的数据保留要求，请参见 Migrating from the Workbench Cluster Plugin。关于替代 Operator 的自定义资源，请参见 Install Workbench 和 Install MLflow。

#准备 global 集群

Alauda AI 2.8.x 使用单集群应用架构。全局资源不再由旧的 Alauda AI Essentials (aml-global) Cluster Plugin 提供。

以下命令必须针对 global 集群 执行，而不是 Alauda AI 工作负载运行所在的集群。请在卸载旧的 Alauda AI Essentials Cluster Plugin 后完成这些操作。

#运行 global-install.sh

下载随 Alauda AI 2.8.x 文档或发布包提供的 global-install.sh 脚本。在 global 集群上，使用 Alauda AI 所安装的集群名称运行该脚本：

kubectl config use-context <global-cluster-context>
bash global-install.sh <target-cluster-name>

该脚本会创建或验证 Alauda AI 使用的全局 OAuth2Client、OIDC Secret 和 ProductEntry 资源。脚本完成后，请验证这些资源：

kubectl get oauth2client -n cpaas-system
kubectl get productentry

平台同步新的 ProductEntry 后，平台控制台中应可见 Alauda AI 条目。

#运行 migrate-roles.sh

在旧的 Alauda AI Essentials plugin 移除后，请在 global 集群上运行随 Alauda AI 2.8.x 发布包提供的 migrate-roles.sh 脚本。

请使用该脚本提供的命令行用法和参数。由于发布脚本尚未添加到文档包中，因此此处暂不提供确切的调用方式。请确认脚本成功完成，并且迁移后的命名空间权限已存在，然后再继续。

#升级 Alauda AI

1. 登录 Web Console，并打开 Administrator 视图。
2. 转到 Marketplace > OperatorHub。
3. 选择目标集群。
4. 打开 Alauda AI。
5. 查看可用版本，并选择 Alauda AI 2.8.x 版本。
6. 确认升级，并等待 OperatorHub 安装状态变为 Installed。

在升级过程中，现有的集群级 AmlCluster 资源 default 会自动升级。升级后的 AmlCluster 会自动启用以下组件：

• PostgreSQL
• Alauda Cache Service for Redis OSS
• Alauda Build of Authorino
• Alauda Build of KServe
• Alauda Build of LeaderWorkerSet

如果需要，您可以在 AmlCluster 配置中手动启用以下可选组件：

• MLflow Operator
• Alauda AI Workbench Operator
• Alauda Build of Serving Runtime

关于 AmlCluster 配置、registry 设置、组件选项和安装详情，请参见 Install Alauda AI。

#升级后操作

#验证 Alauda AI

检查集群级 AmlCluster 资源的状态：

kubectl get amlcluster default

该资源应为 Ready：

NAME      PHASE   READY   REASON
default   Ready   True    Reconciled

#验证 KServe

如果已安装 Alauda Build of KServe，请验证 KServe 实例：

kubectl get kserve default-kserve -n kserve-operator

该实例应报告 DEPLOYED: True：

NAME             DEPLOYED   REASON
 default-kserve   True       UpgradeSuccessful

#验证 Operators 和已迁移组件

验证每个已安装依赖项的 OperatorHub 和工作负载状态：

• 确认每个必需组件均为 Installed，且其 ClusterServiceVersion 报告 Succeeded。
• 确认受启用功能所需的 PostgreSQL、Redis 和 Authorino 服务均已就绪。
• 确认 LWS controller 正在运行，并且一个代表性的分布式工作负载可以启动。
• 确认 MLflow tracking server 已就绪，并且可以访问现有元数据和制品。
• 确认 Workbench 自定义资源已就绪，现有 Workspaces 和 PVC 已存在，并且可以打开一个测试 Workbench。
• 确认现有 KServe 推理服务和具有代表性的模型请求均按预期工作。
• 在 global 集群上，确认 global-install.sh 创建的 OAuth2Client 和 ProductEntry 资源，并验证用户可以通过平台入口打开 Alauda AI。

#验证数据保留

在确认升级完成之前，请验证以下数据仍然可用：

• 用户 PVC 和 Workbench 主目录。
• 现有 Workspaces 和已保留的 WorkspaceKind 资源。
• MLflow 元数据和模型制品。
• 现有推理服务配置和模型数据。
• 分布式工作负载配置和检查点。

如果某个组件未能成功协调，请停止后续迁移，并使用该组件特定的备份和回滚步骤。不要在仍存在自定义资源时删除 CRD；删除 CRD 也可能会删除存储在集群中的自定义资源。