#升级

当您要在现有集群的 OperatorHub 中发布新的 Alauda Build of Rook-Ceph Operator 版本时，请使用此操作步骤。

根据平台版本选择相应路径：

批准 rook-ceph/rook-operator 的待处理 InstallPlan 后，会安装 Operator CSV。在 4.4.1 及更高版本中，此批准操作同时也是对绑定到该软件包的 Ceph 镜像的确认。在 4.4.0 中，控制台不会写入该镜像；您必须使用 kubectl 对其进行修补。

#开始之前

• 确定 Rook Operator 的命名空间。Distributed Storage 向导创建的默认命名空间为 rook-ceph。
• 下载与集群架构匹配的新 Alauda Storage（以前称为 Alauda Build of Rook-Ceph）Operator 软件包。
• 对于内部模式，确认 CephCluster 为 Ready，且 status.ceph.health 为 HEALTH_OK。
• 对于外部模式（spec.external.enable: true），仅升级 Operator。不要修补本地 Ceph 镜像。
• 不要将生成的 CSV 清单编辑为持久化自定义项。后续 OLM 调和可能会覆盖这些编辑。请参阅架构。

#1. 确认使用 Manual 批准

kubectl -n rook-ceph get subscription rook-operator \
  -o jsonpath='{.spec.installPlanApproval}{"\n"}'

输出必须为 Manual。如果不是，请在上传软件包之前将其设置为：

kubectl -n rook-ceph patch subscription rook-operator --type merge \
  -p '{"spec":{"installPlanApproval":"Manual"}}'

在 4.4.1 及更高版本中，您也可以在 Marketplace > OperatorHub > Alauda Storage（以前称为 Alauda Build of Rook-Ceph）中将 Upgrade Strategy 设置为 Manual。

#2. 上传新的 Operator 软件包

使用 violet 上传新的 Alauda Storage（以前称为 Alauda Build of Rook-Ceph）软件包，然后确认 OperatorHub 中显示了目标版本。

按照上架软件包以及 Operator 中的 OperatorHub 操作步骤执行。

上传成功后，OperatorHub 会显示新版本可用。在 installPlanApproval 为 Manual 之前，请勿批准该版本。

#3. 批准 Operator 软件包

OLM 会为新的 CSV 创建一个 InstallPlan。仅批准 Subscription.status.installPlanRef 引用的计划。

kubectl -n rook-ceph get subscription rook-operator \
  -o jsonpath='{.status.state}{"\n"}{.status.installedCSV}{"\n"}{.status.currentCSV}{"\n"}{.status.installPlanRef.name}{"\n"}'

PLAN="$(kubectl -n rook-ceph get subscription rook-operator -o jsonpath='{.status.installPlanRef.name}')"
kubectl -n rook-ceph patch installplan "$PLAN" --type merge \
  -p '{"spec":{"approved":true}}'

kubectl -n rook-ceph get csv
kubectl -n rook-ceph get subscription rook-operator \
  -o jsonpath='{.status.state}{"\t"}{.status.installedCSV}{"\n"}'

#在 4.4.0 上应用 Ceph 镜像

在批准 Operator 软件包后，4.4.0 不会跟随 Ceph 镜像。对于内部模式，请从新的 CSV 中选择 relatedImage 名称为 ceph 的 Ceph daemon 镜像。不要从未筛选的 relatedImages 列表中复制镜像。

CSV="$(kubectl -n rook-ceph get subscription rook-operator -o jsonpath='{.status.installedCSV}')"
CEPH_IMAGES="$(kubectl -n rook-ceph get csv "$CSV" \
  -o jsonpath='{range .spec.relatedImages[?(@.name=="ceph")]}{.image}{"\n"}{end}')"
COUNT="$(printf '%s\n' "$CEPH_IMAGES" | awk 'NF{c++} END{print c+0}')"
if [ "$COUNT" -ne 1 ]; then
  echo "expected exactly one relatedImage named ceph, found ${COUNT}:" >&2
  printf '%s\n' "$CEPH_IMAGES" >&2
  exit 1
fi
CEPH_IMAGE="$(printf '%s\n' "$CEPH_IMAGES" | awk 'NF{print; exit}')"
echo "$CEPH_IMAGE"

如果命令退出时出现错误，请停止操作。在 relatedImages 恰好包含一个 name 为 ceph 的条目之前，不要修补 CephCluster。

列出 CephCluster 对象，并将 spec.cephVersion.image 修补为该唯一镜像。替换 <cephcluster-name>：

kubectl -n rook-ceph get cephcluster

kubectl -n rook-ceph patch cephcluster <cephcluster-name> --type merge \
  -p "{\"spec\":{\"cephVersion\":{\"image\":\"${CEPH_IMAGE}\"}}}"

在4.4.1 及更高版本中，不要运行此修补操作。批准软件包即表示接受绑定的 Ceph 镜像。

#验证 Operator 和数据平面

确认 Operator CSV：

kubectl -n rook-ceph get csv
kubectl -n rook-ceph get subscription rook-operator \
  -o jsonpath='{.status.state}{"\t"}{.status.installedCSV}{"\n"}'

对于内部模式，确认 CephCluster 的运行状况和 Ceph 镜像：

kubectl -n rook-ceph get cephcluster <cephcluster-name> \
  -o jsonpath='phase={.status.phase} health={.status.ceph.health} image={.spec.cephVersion.image}{"\n"}'

• phase=Ready 和 health=HEALTH_OK。
• spec.cephVersion.image 与名为 ceph 的唯一 CSV relatedImages 条目匹配。
• 现有 PVC 仍为 Bound。

对于外部模式，跳过本地镜像检查。现有使用者卷应保持为 Bound。

#如果详细信息页面上的按钮仍处于禁用状态

本节适用于4.4.1 及更高版本。在4.4.0 中没有详细信息页面按钮；请使用 kubectl。

1. 确认用户可以在 rook-ceph 中更新 installplans。

2. 对于内部模式，确认 status.ceph.health 为 HEALTH_OK。

3. 检查 Subscription 和所引用的 InstallPlan：

   kubectl -n rook-ceph get subscription rook-operator
   kubectl -n rook-ceph get installplan

   如果 catalog 中已有更新的 CSV，但没有待批准的 InstallPlan，请检查 startingCSV 是否锁定了 Subscription。不要尝试从详细信息页面修复此锁定。

4. 如果 InstallPlan 已获批准，但在 4.4.1 或更高版本中 Ceph 镜像未发生变化，请确认已安装的 CSV 为 Succeeded，并且 relatedImages 恰好包含一个名为 ceph 的条目。

不要删除 CephCluster 或 PV 对象来取消升级。

#相关主题

• 架构 — OLM 升级概述
• 上架软件包 — 上架 operator 软件包
• operator — Subscription、InstallPlan 和批准策略
• 在内部模式下部署 — 安装时的 升级策略