企业官网建设流程全解析

• 云原生
• 存储
• 容器编排
• 运维

CephX 是 Ceph 集群内部身份认证的基础，密钥（keyring）一旦泄露或长期不更新就会成为安全隐患。本指南围绕 Rook 官方设计文档 design/ceph/cephx-keyring-rotation.md 展开，系统讲解 Rook 如何在不打断 Ceph 集群连接的前提下自动轮换 Ceph 守护进程密钥，又如何通过keyGeneration等机制让用户在维护窗口内安全地轮换 CSI、CephClient 等"非守护进程"密钥。读完本文，你将掌握 Rook CephX 密钥轮换的完整设计思路、CephCluster/CephClient上的配置字段语义、状态字段的解读方式，以及源码层面 types.go 与 cephx.go 中的真实实现细节。

为什么需要 CephX 密钥轮换

Ceph 集群内部所有组件（mon、mgr、osd、mds、rgw 等）之间的通信都依赖 CephX 认证。Rook 创建 Ceph 集群时会为每个守护进程签发长期有效的密钥，并存放于 Kubernetes Secret 中。这些密钥在集群生命周期内几乎不会更新，一旦泄露或需要满足合规要求，管理员只能手动处理，风险高、易出错。

Rook 的设计目标是：

• 守护进程密钥可以自动、透明地轮换，且不会影响 Rook 控制之外的任何 Ceph 连接；
• 涉及外部客户端的密钥（如 CSI、CephClient、镜像对等令牌）由用户在维护窗口内主动触发轮换，并且能够明确判断"轮换何时完成"；
• 不同的密钥类型支持独立触发，避免"一次轮换影响所有客户端"的粗暴做法。

密钥的两大分类

从终端用户体验出发，Rook 将密钥分为两类：

守护进程密钥（daemon keys）

仅由 Ceph 集群内部使用，Rook 可以自动轮换而不会破坏任何外部连接，包括：

• Admin 密钥（client.admin）
• mon、mgr、osd、mds、rgw
• nfs、log-rotator、crash-collector
• rbdmirror 与 cephfsmirror 的内部（非对等）密钥

非守护进程密钥（non-daemon keys）

轮换可能影响非 Rook 控制的连接，需要用户在维护窗口内协调操作：

• CephClient 密钥
• RBD / CephFS 镜像对等令牌（peer tokens）
• CSI 密钥

CSI 密钥是最特殊的非守护进程密钥：轮换会直接影响所有挂载了 RBD / CephFS PVC 的应用 Pod，管理员可能需要重启或 drain/undrain 所有相关节点才能让挂载从旧密钥切换到新密钥。因此 CSI 密钥只提供一次性轮换选项（KeyGeneration），且默认走"重叠轮换"流程（见下文）。

轮换策略的接口设计

设计文档提出了一个统一的轮换基接口：

keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: <int> # used with KeyGeneration keepPriorKeyCount: <int> # only present to configure overlapping rotation

字段语义如下：

关于keyGeneration有两个值得注意的设计点：

1. 代际值不要求连续递增，1 -> 5同样合法（但 CRD 校验禁止代际回退，见下文源码分析）；
2. 设计文档曾考虑过once、always、按 Ceph 版本选择、按DATETIME选择等方案，最终均被否决：once需要额外记录首次观测时间才能避免每次 reconcile 重复触发；always需要用户手动监控并取消配置，容易出错；按 Ceph 版本选择无法支持"已在最新版本上按需轮换 CSI 密钥"；DATETIME在多密钥场景下难以准确追踪轮换时间。代际（generation）能清晰表达真实状态且接口简单，因此被采纳。

源码中的实际约束

从当前仓库源码看，CRD 层面对该接口做了一些收敛与校验，定义于 pkg/apis/ceph.rook.io/v1/types.go：

type CephxConfig struct { // +kubebuilder:validation:Enum="";Disabled;KeyGeneration KeyRotationPolicy CephxKeyRotationPolicy `json:"keyRotationPolicy,omitempty"` // +kubebuilder:validation:Minimum=0 // +kubebuilder:validation:Maximum=4294967295 // +kubebuilder:validation:XValidation:message="keyGeneration cannot be decreased",rule="self >= oldSelf" KeyGeneration uint32 `json:"keyGeneration,omitempty"` // +kubebuilder:validation:Enum=aes;aes256k KeyType CephxKeyType `json:"keyType,omitempty"` // +kubebuilder:validation:XValidation:message="keyGeneration cannot be removed once set",rule="!has(oldSelf.keyGeneration) || has(self.keyGeneration)" }

可以确认的几点：

• 当前 CRD 枚举只放行Disabled与KeyGeneration，设计文档中的WithCephVersionUpgrade尚未在公开 API 中开放（源码内部 cephx.go 已存在shouldRotateWithCephVersionUpdate辅助函数，说明该路径已在实现层面预留）；
• keyGeneration一旦设置就不能删除、不能回退，由 CEL 规则在 API 层强制；
• 额外引入了keyType（aes/aes256k）字段，可指定 CephX 密钥加密类型；当KeyRotationPolicy为Disabled时修改keyType不会触发轮换。

CephCluster 上的配置：守护进程密钥轮换

守护进程密钥的轮换配置只出现在CephClusterCR 上，任何子 CR（如CephFilesystem）自动继承对应 CephCluster 的配置。这样管理员可以按集群粒度选择性开启，同时保持 API 简洁。Ceph 社区建议在每次 Ceph 版本更新时轮换，因为此时 Rook 本来就会重启守护进程，且管理员通常已有维护窗口，对集群连通性与性能无额外影响。

spec: # ... security: cephx: daemon: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: <int> # used with KeyGeneration csi: {} # discussed more later # (room for future spec.security.cephx options) # (room for future spec.security options) # ...

Rook 曾考虑在 operator 级别用全局环境变量ROOK_ROTATE_DAEMON_CEPHX_KEYS_OLDER_THAN控制，但全局配置无法在修改时触发各控制器 reconcile；把配置挂在 CephCluster 上，控制器就能在用户修改配置时获得 reconciliation 事件，这是最终选择 CephCluster 字段的根本原因。

可被自动轮换的守护进程密钥清单（设计文档原文）：

• mon —— 所有 mon 共享同一个密钥
• mgr
• osd
• mds
• rgw
• nfs
• rbdmirror —— 守护进程密钥自动轮换，但对等令牌不会自动轮换
• cephfsmirror —— 与 rbdmirror 相同
• log-rotator
• crash-collector

此外，Rook 用来执行 Ceph 命令的 admin 密钥也会自动轮换，且实现上必须保证 admin 密钥轮换不会阻塞其他密钥的轮换（其专用流程见后文）。

重叠轮换（Overlapping Rotation）：解决大规模节点迁移难题

CSI 密钥轮换要求所有挂载了 PVC 的节点完成 drain/undrain（或重启），以把挂载从旧密钥切换到新密钥。但服务票据 TTL（默认窗口约为2 * auth_service_ticket_ttl，见后文）通常只有几小时，大型集群不可能在一次维护窗口内更新全部节点。

为此 Rook 设计了重叠轮换：

1. Rook新建一个带新密钥的 Ceph client（用户），但不删除旧用户/旧密钥；
2. Rook 更新 CSI Secret 指向新用户+新密钥；
3. 此时进入迁移窗口：新的 PVC 挂载使用新密钥，旧的挂载继续使用旧密钥（因为旧用户尚未销毁）；
4. 管理员完成所有节点更新后，通过配置向 Rook 表明旧密钥不再需要，Rook 再删除旧密钥（自动探测留作未来练习）。

重叠轮换只针对CSI 密钥实现，不会应用于CephClient资源——因为每个 CephClient 就是单一 client ID 及其密钥，需要传播凭据的用户可以直接"新建 CephClient → 传播新凭据 → 删除旧 CephClient"来实现等价效果。未来 RBD/CephFS 镜像对等密钥也适合重叠轮换，但当前对等用户名在 Ceph 侧是硬编码的，暂无法实现。

重叠轮换通过keepPriorKeyCount配置：

• 通常设为1，保留 1 个旧密钥供应用迁移；
• 设为0表示迁移完成后立即删除旧密钥。

源码中该字段在 types.go 中定义为CephXConfigWithPriorCount.KeepPriorKeyCountMax（uint8，Minimum=0、Maximum=10），并有一个重要语义：它表示最多保留的旧密钥数量上限，实际保留数以真实存在的密钥数为准（例如配置为 2 但当前只有 1 个旧密钥，就只保留 1 个）。CSI 密钥轮换的实际执行位于 pkg/operator/ceph/csi/secrets.go：Rook 通过deleteOldKeyGen与KeepPriorKeyCountMax计算删除数量（deleteCount= 当前密钥数 - keepPriorCount - 1），并把 CSI 用户名加上代际后缀（<baseName>.<keyGeneration>，见generateCsiUserIdWithGenerationSuffix），从而支持同时存在多代密钥。

状态报告：用户如何判断轮换完成

为了让用户确定"轮换是否完成"，所有相关 CR 统一上报两个状态字段：

keyGeneration: <int> keyCephVersion: "20.2.0" # e.g.

• keyGeneration（int）：最近一次成功 reconcile 的密钥代际。即使未开启轮换策略也会更新。密钥首次创建时代际为1；0表示初始 reconcile（含密钥创建）尚未完成，或密钥早于本功能实现就已存在。
• keyCephVersion（string）：签发当前在用密钥的 Ceph 版本，格式必须与CephCluster.status.version.version一致（如20.2.0）以便直接比较；空字符串表示版本未知（典型于 brownfield 存量集群）。

判断完成的标准：

• WithCephVersionUpgrade场景：status.keyCephVersion与部署镜像中的 Ceph 版本一致即完成；
• KeyGeneration场景：status.keyGeneration >= spec.keyGeneration即完成；
• 重叠轮换额外上报priorKeyCount（int）：当前仍在生效的旧密钥数量。

这些状态在所有 Rook 资源首次创建 CephX 密钥时就会写入，即使未开启轮换，用户也始终能知道密钥的版本与代际（或通过缺失得知信息未知）。

源码中对应结构为 types.go 的CephxStatus（KeyGeneration、KeyCephVersion、KeyType），状态计算逻辑在 cephx.go 的UpdatedCephxStatus：首次创建置代际1；未轮换时保留旧状态（尤其保留KeyCephVersion）；轮换后代际自增，若KeyGeneration策略指定的目标代际更大则直接取目标值。

另外，为避免 bug 或状态丢失导致 Rook 对"某个组件到底生成过多少代密钥"失去跟踪，设计文档建议把当前keyGeneration追加到 Ceph auth client 名称中（这正是 CSI 用户名后缀的实现方式），使 Rook 能随时列出密钥、确保只存在当前代与期望数量的历史代。

轮换的通用工作流

密钥轮换在每个 reconcile 控制器内部就近执行——凡是 Rook 创建/删除 Ceph 守护进程时会创建/删除密钥的地方，轮换逻辑就在旁边。这样密钥轮换能立即引起守护进程重启，从而在任何意外错误导致集群或子资源离线前尽早暴露问题。通用流程如下：

1. 对某个 Rook CR 开始 reconcile；
2. 读取当前 CR 的 spec + status（所有 reconcile 本就有）；
3. 运行 cmd-reporter job 探测待部署 Ceph 容器镜像中的版本（cephImageVersion）（所有 reconcile 本就有）；
4. 对每个守护进程 Deployment，获取其当前 CephX 密钥：
   • 若密钥不存在，则创建，keyGeneration记为1，keyCephVersion记为cephImageVersion；
5. 检查 spec 配置决定是否轮换：
   • KeyGeneration策略：spec.keyGeneration > status.keyGeneration则轮换；
   • 按 Ceph 版本策略：cephImageVersion高于状态中的版本则轮换；
6. 用最新内容更新存放密钥的 Secret（reconcile 本就包含）；
7. 若创建/轮换了密钥，必须保证守护进程重启：Rook 在 Pod spec 上施加一个随每次密钥 Secret 更新而变化的 annotation，强制 Pod 重启。该 annotation 不属于面向用户的 API，operator 不会读取它做任何决策，唯一目的就是"密钥轮换必定触发重启"；
8. 若创建/轮换了密钥，更新 cephx 状态（keyGeneration取 spec 目标值，keyCephVersion取cephImageVersion）。

判定是否轮换的核心函数是 cephx.go 的ShouldRotateCephxKeys。从源码可以确认两点关键前提：

• Rook 依赖 Ceph 的ceph auth rotate命令，其支持版本下限为CephAuthRotateSupportedVersion = 19.2.3（cephx.go），运行中的 Ceph 版本低于此值时不轮换；
• 状态代际为0（密钥尚未初始化）时不轮换。

CephCluster 上的轮换执行细节

通用 CephCluster 流程

1. CephCluster 守护进程均属 daemon 类，reconcile 读取spec.security.cephx.daemon决定是否轮换；
2. 需要轮换时依次处理：
   • admin 密钥：Rook 创建的第一个密钥，第一个轮换；轮换后视子 reconcile 引用方式，可能需要重启 operator 的 reconcile manager；
   • mon 密钥：需要特殊流程——先不轮换密钥地更新 mon Deployment，再轮换密钥，最后重启 mon Deployment 让它们拿到新密钥；
   • 更新 CephCluster 状态中的 mon 信息；
   • mgr 密钥：逐个 mgr 轮换并更新/重启对应 daemon；
   • osd 密钥：OSD 没有关联的 keyring Secret，必须确保所有 OSD Deployment 的 "activate" init container 拿到最新密钥并更新给 "osd" Pod。

分 daemon 类型独立跟踪状态的意义在于：避免 reconcile 中途重启后重复轮换前面已经轮换过的密钥。例如 OSD 更新耗时较长，很可能在 OSD 更新中途需要重启 reconcile，此时不需要再轮换 admin/mon/mgr 密钥。CephCluster 的完整状态示例：

spec: security: cephx: daemon: {} csi: {} rbdMirrorPeer: {} status: # ... cephx: admin: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. mon: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. mgr: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. osd: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. rbdMirrorPeer: # cluster-level RBD mirror peer key (client.rbd-mirror-peer) keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. crashCollector: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. exporter: keyGeneration: 3 # e.g. keyCephVersion: "20.2.2" # e.g. csi: {} # discussed more below

对应源码类型为 types.go 的ClusterCephxConfig，它把配置分为四块：allowedCiphers（高级项，设置auth_allowed_ciphers，可影响集群可用性）、daemon、rbdMirrorPeer（轮换会更新镜像对等令牌，影响已有对等连接）、csi。

admin 密钥轮换：防"砖机"的专门设计

admin 密钥轮换是整个设计中最危险的一步。当前rook-ceph-monSecret 中保存着权威的client.adminkeyring（"primary admin keyring"）。虽然client.admin理论上可以自己轮换自己的密钥，但"轮换密钥"与"更新 Secret"两步无法原子化：若 reconcile 或 operator 在两步之间失败，集群将无法恢复。

为此 Rook 引入一个临时 admin 用户client.admin-rotator，其唯一职责就是轮换主 admin keyring，轮换完成后立即删除。它的凭据存放在独立的rook-ceph-admin-rotator-keyringSecret 中（不往rook-ceph-mon里加临时字段，避免复杂性与风险）。

轮换流程（完整 10 步）：

1. 以client.admin身份：ceph auth get-or-create client.admin-rotator（授予 admin 权限）；
2. 创建/更新rook-ceph-admin-keyringSecret，写入client.admin-rotator的 keyring；
3. ROTATE 前检查：以client.admin-rotator运行ceph auth ls，确认其权限可用；
4. 以client.admin-rotator身份：ceph auth rotate client.admin；
5. 以client.admin运行ceph auth ls，确认其权限仍可用；
6. 更新磁盘上的 ceph 配置文件，写入新的client.adminkeyring；
7. 更新rook-ceph-monSecret，写入新的client.adminkeyring；
8. 以client.admin身份：ceph auth rm client.admin-rotator；
9. CLEANUP：删除rook-ceph-admin-keyringSecret；
10. 更新CephCluster.status.cephx.admin。

post-mon-startup 动作：admin 密钥轮换应在 mon 更新之后进行。这一点在 Ceph 升级场景下尤为重要——若当前 Ceph 版本不支持ceph auth rotate而新版本支持，必须先升级 mon 再轮换（mon.密钥同理）。触发条件为CephCluster.spec.security.cephx.daemon指示需要轮换。

CephCluster 启动时的恢复流程：如果轮换在ROTATE步骤之后失败、或 operator 在此后重启，rook-ceph-monSecret 的data.keyring可能是错误信息，新 reconcile 将无法执行任何 admin 操作，集群"砖化"。因此 reconciler 必须在任何其他 admin 操作之前先恢复中断的 admin 轮换：

1. 读取 Secret（与现状相同）；
2. 从 Secretdata.keyring加载client.admin（与现状相同）；
3. 若 Secretdata.rotatorKeyring存在，说明此前轮换在中途失败，需要恢复：
   • 以client.admin运行ceph auth ls：
     • 若成功且输出中不存在client.admin-rotator：说明最后的 CLEANUP 步骤失败，直接 GOTOCLEANUP；
     • 否则（即使auth ls失败）：轮换失败于ROTATE到CLEANUP之间，从 Secretdata.rotatorKeyring加载client.admin-rotator，GOTOROTATE；
4. 继续正常的 CephCluster reconcile。

CSI 密钥轮换

Ceph-CSI 的 Deployment（若由 Rook 管理）位于 operator 命名空间，但密钥按 CephCluster 维度创建，因此 CSI 轮换配置同样挂在CephCluster上。CSI 轮换要求管理员手动重启或 drain/undrain 节点，Rook不提供自动轮换，只实现一次性轮换，并且为了容纳任意长的维护窗口，CSI 使用重叠轮换：

spec: # ... security: cephx: daemon: {} # discussed above csi: keyRotationPolicy: Disabled | KeyGeneration keyGeneration: <int> # used with KeyGeneration keepPriorKeyCount: 1 # (room for future spec.security.cephx options) # (room for future spec.security options) # ...

重要约束：WithCephVersionUpgrade不支持用于 CSI 密钥——除非 Rook 能验证密钥轮换不会影响既有 PVC 挂载连通性，否则对该值直接返回错误。

CSI 轮换在 CephCluster reconcile 中完成：Ceph-CSI 的 provisioner 与 node plugin 密钥使用CephCluster.spec.security.cephx.csi（而非...daemon）判定是否轮换；轮换后更新状态：

kind: CephCluster # ... status: # ... cephx: # (status from CephCluster daemon rotations) csi: keyGeneration: 2 # e.g. keyCephVersion: "20.2.1" # e.g. priorKeyCount: 1 # e.g.

实现层面，CSI 密钥轮换的核心逻辑集中在 pkg/operator/ceph/csi/secrets.go：先读取现有密钥并用ShouldRotateCephxKeys判定是否轮换；随后生成带代际后缀的新用户名（client.rbd.<pool>.<keyGeneration>形式），先创建新密钥再按KeepPriorKeyCountMax清理旧代密钥，最后把status.cephx.csi.priorKeyCount更新为实际保留的旧密钥数（见getPriorKeyCount）。CSI 相关的单元测试覆盖于 pkg/operator/ceph/csi 目录。

非守护进程密钥轮换：CephBlockPool / CephFilesystem / CephClient

除 CephCluster 外，以下 CR 也承载非守护进程密钥：

• CephClient—— 创建的可任意使用的 client 有一个关联密钥；
• CephBlockPool—— 为池生成镜像对等令牌（peer）；
• CephFilesystem—— 为文件系统生成镜像对等令牌（peer）。

CephBlockPool：对等令牌跟随集群级 rbdMirrorPeer

RBD 镜像对等令牌内的密钥在 Ceph 侧被硬编码为client.rbd-mirror-peer用户，因此单个 RBD 镜像密钥在 CephCluster 级别轮换（即上文status.cephx.rbdMirrorPeer），但 CephBlockPool 仍需更新自身状态，标识对等令牌已换成最新版本。

CephBlockPool 控制器应在父级 CephCluster 的status.cephx.rbdMirrorPeer更新时触发 reconcile；创建 bootstrap token 时把CephCluster.status.cephx.rbdMirrorPeer拷贝到自己的status.cephx.peerToken：

kind: CephBlockPool # ... status: # ... cephx: peerToken: keyGeneration: 2 keyCephVersion: "20.2.2"

对应的源码类型为 types.go 的PeerTokenCephxStatus（peerToken字段内嵌标准CephxStatus）。

CephFilesystem mirror

设计与rbdMirrorPeer/peerToken一致，针对 CephFS 镜像设计做相应适配。

CephClient：最简单的一对一接口

CephClient 只有一个密钥，既可当守护进程密钥也可当对等令牌，因此接口被简化为直接内嵌CephxConfig（源码 types.go 的ClientSecuritySpec，状态字段见CephClientStatus.Cephx）：

kind: CephClient # ... spec: # ... security: cephx: keyRotationPolicy: Disabled | WithCephVersionUpgrade | KeyGeneration keyGeneration: <int> # used with KeyGeneration # (room for future spec.security options) # ... status: cephx: keyGeneration: 1 # e.g. keyCephVersion: "20.2.0" # e.g.

未使用密钥的清理

Ceph 会自动创建一些 Rook 并不使用的密钥。Ceph 团队表示未来会修改 Ceph 停止创建这些密钥；在改动落地之前，Rook 删除它们是安全的（未使用密钥无需轮换，直接删除）：

• client.bootstrap-rgw
• client.bootstrap-rbd
• client.bootstrap-mgr
• client.bootstrap-mds

依赖与 CephX 技术背景

Rook 的密钥轮换依赖Ceph Tentacle（v20）新增的ceph auth rotate命令（Ceph PR #58121）。理解 CephX 的几个关键技术点对开发与排障至关重要：

• Rook 铸造的 CephX 密钥只用于守护进程的初始连接；Ceph 内部所有连接使用具有阶梯式过期时间的 service 密钥；
• 默认情况下，service 密钥允许密钥轮换后至少 2 小时窗口供客户端更新：共有 3 个 TTL 分别为 1 小时、2 小时、3 小时的 service 密钥，即使第一个 TTL 即将到期，到 3 小时 TTL 到期也仍有至少 2 小时；
• Ceph 不允许同一 client/daemon 的 keyring 中存在多个密钥：轮换时旧密钥被移除、新密钥直接替换，没有"双密钥并存"的过渡期（这正是重叠轮换通过"新建用户而非双密钥"实现的原因）；
• auth_service_ticket_ttl与auth_mon_ticket_ttl配置可缩短/延长上述窗口，但生效不是即时的（内部 service 密钥更新需要时间）；
• debug_auth=30可输出最大级别的 CephX 调试日志，是开发阶段的排障利器。

与既有方案的对比（Prior Art）

• Kubernetes 静态加密密钥轮换：K8s 文档中的做法由用户负责生成密钥，而 Rook 负责生成 CephX 密钥，因此该设计无法直接迁移；
• IBM Credential Rotator Operator：自动轮换应用密钥并随后重启应用 Pod，通过PreviousResourceKeyID状态展示信息。由于 Ceph 密钥没有与轮换关联的 ID，这与 Rook 自行跟踪"密钥版本（key version）"元数据的思路类似，但不完全相同。

源码阅读路线图

如果想在仓库中继续深挖本设计的具体实现，推荐按以下路径阅读：

• pkg/apis/ceph.rook.io/v1/types.go：ClusterSecuritySpec、ClusterCephxConfig、CephXConfigWithPriorCount、CephxConfig等公开 API 类型；
• pkg/apis/ceph.rook.io/v1/types.go：CephxStatus状态结构；
• pkg/operator/ceph/config/keyring/cephx.go：ShouldRotateCephxKeys、UpdatedCephxStatus及CephAuthRotateSupportedVersion（19.2.3）版本门槛；
• pkg/operator/ceph/config/keyring/cephx_test.go 与 pkg/operator/ceph/cluster/mgr/mgr_test.go：轮换判定与状态更新的单元测试；
• pkg/operator/ceph/csi/secrets.go：CSI 重叠轮换实现（带代际后缀的用户名、旧密钥清理、priorKeyCount上报）；
• pkg/apis/ceph.rook.io/v1/types.go：PeerTokenCephxStatus对等令牌状态。

总结

Rook 的 CephX 密钥轮换设计以"守护进程密钥自动轮换、非守护进程密钥由用户按需触发"为总原则，用keyGeneration代际机制提供了幂等、可观测、防回退的轮换接口，用重叠轮换解决了 CSI 密钥轮换与大规模节点维护窗口不匹配的工程难题，并通过临时client.admin-rotator用户与完整的失败恢复流程把最危险的 admin 密钥轮换风险降到可控范围。配合status.keyGeneration与status.keyCephVersion两个状态字段，管理员可以精确判断任何一次轮换是否完成，从而在维护窗口内安全地协调应用侧密钥更新。

• 云原生
• 存储
• 容器编排
• 运维