#升级

Alauda GPU Management 作为一个 OLM operator 提供。升级时有两项内容可以独立变更：operator（及其 operands）版本，以及 GPU 驱动版本。本页将介绍这两部分内容。

#升级前准备

1. 检查目标组合对应的 Versions and Components 和 Compatibility。
2. 如果 ACP 强制执行镜像白名单策略，请在目标业务集群中更新新 operand 和驱动镜像 tag 的 ImageWhiteList 条目。
3. 备份 ClusterPolicy 实例的 YAML。

#升级 operator

bundle 声明了 olm.skipRange，因此任何更早版本都可以直接升级到目标版本，而无需经过中间版本。

1. 进入 Administrator > Marketplace > OperatorHub（或 Installed Operators），切换到目标集群，然后打开 Alauda GPU Management。
2. 批准升级到目标版本。在 Manual 升级策略下，install plan 会等待批准。
3. 等待 subscription 报告新版本已成功，并且 controller pods 正在运行新镜像。

ClusterPolicy 及其受管 operands 会被协调到新版本。版本未发生变化的 operands 将保持不变。

#更改驱动版本

更常见的持续变更是驱动版本变更，而不是 operator 版本变更。在 precompiled-driver 模式下，驱动版本通过 ClusterPolicy 的驱动设置（driver.version）进行更改，该设置会为节点内核选择新的 precompiled driver 镜像。

1. 为每个节点内核配置文件准备新的驱动镜像（导入 precompiled tuple，或镜像同步 upstream 镜像），具体请参见 Configure the driver mode。
2. 如果 ACP 强制执行镜像白名单策略，请使用新的驱动 tag 更新 ImageWhiteList。
3. 在驱动 CR 中更改驱动版本。
4. driver manager 会协调滚动发布。更改驱动会重新加载节点上的 kernel modules，因此该节点上的 GPU workloads 在驱动重新加载期间会失去 GPU 访问权限。这是预期行为；请将此次变更规划为节点维护窗口，并停止或重新调度那些不能中断的 workloads。

支持通过此流程进行跨驱动版本迁移（例如在 570 和 580 分支之间切换）。在 modules 重新加载期间，GPU 会出现一段失联窗口，随后恢复。

#同时升级 operator 和驱动

同时升级 operator 版本和驱动版本是受支持的，并且已由上述各自的流程覆盖。这两个操作不是原子的——operator 升级和驱动重新加载会独立完成——因此，请将组合变更视为先进行 operator 升级，再进行驱动滚动发布，并据此为驱动重新加载安排节点维护窗口。

#验证

升级完成后，请确认 operator 版本和 GPU allocatability：

kubectl get clusterpolicy
kubectl get node ${nodeName} -o jsonpath='{.status.allocatable}'

然后按照 Verification 中的说明运行一个简短的 GPU workload。