Rook/Ceph 升级后：msgr2、host 网络和服务端密钥

最先出错的是滚动预期#

最初把这次变更理解得太窄，漏看了 Rook 的 ApplyNetworkEnv。实际 ROOK_MSGR2 从 false 变成 true，进入了多个 daemon 的 Pod 模板，触发滚动。

02:38–02:39 曾同时看到 4 个 OSD down。 当时还没有开始生产卷重挂。先暂停扩大业务动作，短暂把 operator 从 1 缩到 0；已经提交给 Deployment 控制器的更新仍然继续，不能靠停 operator 撤回。

等 18 OSD up/in、PG 恢复 clean、没有新 crash 后，再恢复 operator 和后续步骤。这是一次真实的预估偏差，后面的两个窗口才把串行保护明确写死。

最终判据不是 requireMsgr2: true，也不是服务端开着 3300。RBD 从 sysfs 的 client_id 对应到 debugfs 客户端，检查 monmap、osdmap；CephFS 同时核对实际挂载模式和客户端 map。只读取需要的 map，不打印完整认证选项或 keyring。

06:55 收尾时，68 个生产 RBD、23 个 CephFS 内核客户端全部 v2。客户端数量是最终实际清点值，不把操作前的 20 个 CephFS 客户端数当成固定常量。

镜像和模板也会跟着重建#

QQ 组停旧实例后，原镜像标签出现 404，卡在拉取和初始化。后面靠原版本镜像及节点缓存恢复，应用版本和 PVC 没改，但中断比预估长。

正在运行不代表镜像还能拉到。 主容器、initContainer、候选节点都要核对；Always 还要检查原引用能否解析。

虚机也有类似问题：VM 模板已经是 host-passthrough，部分运行中的 VMI 仍是 host-model。关机再启动会把历史模板变化一起带进来。这次结合此前验证核对后执行，不能只检查根盘 UID 就按启动键。

数据库各有自己的控制循环#

Redis 那组尤其不能只看 Sentinel 的一句成功。旧主写暂停阻碍了降级，Operator 又根据实际角色重建主从，两个控制循环来回纠正。解除暂停后，真实 role、复制 offset、master Service 和三个 Sentinel 才恢复一致。

MariaDB 没有通过 RESET MASTER、手改 GTID 或清 binlog 把错误压下去。原主可写、副本只读、复制追平已经恢复，历史 GTID 遗留仍在。后续节点维护不能把“此刻 lag=0”当作自动切主必然可靠。

这些都是本次发生的偏差。复制恢复、入口通过，不足以反推这一段业务零中断或证明所有业务语义零损失。

先把串行保护写实#

Rook v1.19.10 的 OSD 更新并发默认值是 20。前一个窗口吃过亏，这次明确设为 1，并保留原生停止和继续检查。源码对应 OSD 更新逻辑。

最终关键配置如下。mon.disabled 只在 B/C 阶段临时设为 true，结束后恢复 false：

1
cephClusterSpec:
2
  network:
3
    provider: host
4
    addressRanges:
5
      public: [10.1.16.0/24]
6
    connections:
7
      requireMsgr2: true
8
  storage:
9
    osdMaxUpdatesInParallel: 1
10
  upgradeOSDRequiresHealthyPGs: true
11
  skipUpgradeChecks: false
12
  continueUpgradeAfterChecksEvenIfNotHealthy: false
13
  healthCheck:
14
    daemonHealth:
15
      mon:
16
        disabled: false

暂缓的是 MON 后台自动调谐，Kubernetes 探针和持续 quorum 检查仍在。timeout=0 不能替代这个暂停开关。

网络要测双向，也要看实际监听#

三台主机和三台普通 Pod，共六个来源，分别访问三个节点的目标端口；另外验证 hostNetwork DNS，以及主机到旧 MON、OSD、MDS 的路径。临时端口探针删除、监听释放后才发布 host 配置。

RGW 有个很实际的变化：原来 Service 的 80 指向 Pod 的 8080，host 模式下进程监听 80，Service 的 targetPort 也变成 80。原 Service 地址保留，但两副本并不保证这次端口切换零中断，所以必须验证真实 S3 put/get/hash。

NodeLocal DNS 的 8080、MetalLB 的 7472 是已有监听，不能为了 Ceph 清掉。host 网络还把 MGR HTTP、指标和 exporter 端口带到了主机网络；本次核实公网只经既有入口，没有直接映射到三个节点。

11:39 发布 C，11:54:32 后端完成。operator 日志每次都先等 PG clean，再轮到下一只 OSD；这个窗口的采样最低为 17 OSD up，没有观察到两只同时 down。

MON 让 Rook 自己逐个换#

v1.19.10 会把网络不匹配的 MON 放入 failover 队列，由健康检查逐个处理。这里没有叠加人工删除或缩容 MON。队列处理源码

实际替换顺序是：

monmap epoch 从 20 到 26。过程中有 3→4→3 的成员变化，见到过 2/3、3/4 的多数状态；2/4 不满足多数，不能只数“还有两个 MON 活着”。

12:04:25 全部收敛，再完整观察 30 分钟，最后跨节点重挂测试卷。12:44 收尾。host 阶段没有重启业务 Pod、数据库、虚机或宿主机，生产卷依靠新 map 学习服务端地址。

新 MON 仍监听 6789#

原先从 Pod 端口声明推断新 MON 只提供 3300，现场不成立。新的 k/l/m 在 monmap 和主机 ss 中都保留 3300/6789。

因此本文只说 CSI 使用 3300、实际客户端是 v2。服务端 v1 兼容监听没有被强制关闭。

空闲客户端的旧 OSD map#

迁移结束后，所有 RBD map、全部 MON/MDS map 都已更新，但 12 个低活动 CephFS 客户端还缓存着旧 OSD 地址。

对已有非凭据文件做 4 KiB 直接只读访问后，10 个自动刷新并读取成功，首次读取最长 9.706 秒。剩下两个是同一录播卷在两个节点上的空目录挂载：只有根和两个空子目录，OSD requests/homeless 均为 0，元数据访问正常。

这两个缓存没有靠重启业务或向业务目录写探针来刷新。已有数据访问、空卷无请求和新挂载分别验证，记录里保留了这个例外。只看 debugfs 中还有一个旧地址，判断不了是否有 I/O 故障；也不能据此宣称全部闲置 map 都已更新。

Helm 回滚不等于网络恢复#

Rook 写进 Ceph monitor 配置库的 public_network，不会因为 values 删除该字段或切回 Pod 网络就自动消失。网络配置源码

回退还得区分 MON 有没有换身份。后端地址、Ceph 配置库、当前有效 monmap、CSI 端点都要处理，不能把旧 g/i/j 的快照直接覆盖回来。此次没有实际回退。

三节点 host 模式下，每节点一个 MON。以后坏一台，剩余 2/3 可以维持仲裁，但不能指望另外两台再自动容纳第三个 MON；要恢复原节点，或有额外的合格节点。

代次只推进一次#

本集群相关当前 generation 均为空或 0，因此目标取 1。其他集群要先读自己的当前代次。渲染后的关键配置是：

1
cephClusterSpec:
2
  security:
3
    cephx:
4
      daemon:
5
        keyRotationPolicy: KeyGeneration
6
        keyGeneration: 1
7
      csi:
8
        keyType: aes

CSI 的 aes 原来就在 Chart 默认值中，实际只新增 daemon 的两项字段。完整渲染 18 个对象，只有 CephCluster 改变；四只 CSI Secret 只记录元数据，不读取值。

13:31:22 发布 cluster revision 43。仍是 Ceph 19.2.6，没有把轮换和 Ceph 20 升级合成一次变更。

代次是一次轮换的目标状态。观察程序失败、状态暂时没填全，都不是再次增加 generation 的理由。

admin 更新会影响管理工具#

Rook 原生流程会创建临时 rotator 身份，验证新 admin，更新管理 Secret，清理临时身份，再重启 operator。13:31:57 开始，13:32:00 已记录成功重启。

日志里出现了：

1
successful admin cephx key rotation requires the current cluster reconcile to restart

这是这条控制路径的预期结果，需要用后续状态和认证结果确认；不能看到 error 就把旧 Secret 覆盖回去。固定版本实现

另一个提前发现的问题是 Toolbox。现场 v1.19.10 Chart 的内联脚本只监测 MON 端点，启动时复制一次 admin 密钥，之后不重载 keyring。不能拿其他版本的 Toolbox 行为替它作保证。

先保留独立观察 Pod，用原生客户端直接消费投射的认证文件，绕开旧 keyring 缓存：

1
ceph --keyring /dev/null \
2
  --keyfile /var/lib/rook-ceph-mon/secret.keyring status

这里没有输出文件内容，也没有把密钥塞进命令行。它仍要等 Kubernetes 把新 Secret 投射到 Pod。

现场记录了约 80 秒管理查询认证间隙、12 次查询失败，期间三卷 I/O 继续通过。13:33:14 查询恢复；新认证验证后，正常重建唯一 Toolbox Pod，13:35:29 默认认证通过。

停止轮换也不会撤回已经生成的新密钥。旧 Helm values、旧 Secret、旧 etcd 快照，都不能单独当成密钥回滚方案。

一个可选字段把验收脚本挡住了#

13:50，CephCluster 已经 Ready，旧服务端密钥归零，但 SSD 文件系统的 status.cephx.daemon.keyType 没有值，最初的验收脚本在这里报错。

原因在名字前缀：ceph-filesystem- 同时匹配 ceph-filesystem-hdd-。SSD 那组先完成时，Rook 的 best-effort 类型采样把还在滚动的 HDD 那组也算进来，看到 [aes256k aes]，便没有填写可选字段。MDS 状态采样代码

核对日志和源码后，验收使用当前 generation、原生服务端安全检查、MDS 主备和数据访问结果；有类型字段的仍要求为 aes256k。没有为了补一个显示字段再次轮换。

13:53:13 核心验收通过：全部目标服务端组 generation 1，24 个旧服务端实体归零，MGR/OSD 报告 aes256k，两套 FS 主备正常，四只 CSI Secret 的 UID/resourceVersion 不变。

随后只解除已经消失的三项服务端检查的历史静默：

1
AUTH_INSECURE_SERVICE_KEY_TYPE
2
AUTH_INSECURE_SERVICE_TICKETS
3
AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE

原生服务票据没有被强制擦除。后续若出现正常轮转过渡，需要跟踪自然更新，不能为了立刻消告警把旧票据清空。