4. 版本漂移检测方法（二）：ceph versions 与 ceph osd versions 实战

在 Rook Ceph 生产环境中，版本漂移往往不是瞬间发生的，而是随着节点滚动升级、OSD 重建或镜像回滚逐步扩散。本节聚焦两个核心命令——ceph versions 和 ceph osd versions，通过 JSON 输出解析技巧，精准定位集群中哪些组件、哪些 OSD 已经偏离目标版本。

4.1 ceph versions：全组件版本分布快照

该命令聚合集群内所有守护进程（MON、MGR、OSD、MDS、RGW）的版本信息，返回一个按组件类型分组的 JSON 对象。执行方式：

# 在 Rook 工具箱中执行
kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph versions

典型输出结构如下：

{
    "mon": {
        "ceph version 18.2.2 (..."): 3
    },
    "mgr": {
        "ceph version 18.2.2 (..."): 2
    },
    "osd": {
        "ceph version 18.2.2 (..."): 9,
        "ceph version 18.2.0 (..."): 1
    },
    "mds": {},
    "rgw": {}
}

4.2 ceph osd versions：OSD 级别精确漂移定位

当 ceph versions 发现 OSD 版本不一致时，使用 ceph osd versions 进一步获取每个 OSD 的版本映射。该命令返回一个以 OSD ID 为键、版本字符串为值的 JSON 对象：

ceph osd versions

{
    "osd.0": "18.2.2",
    "osd.1": "18.2.2",
    "osd.2": "18.2.2",
    "osd.3": "18.2.0",   # 漂移 OSD
    "osd.4": "18.2.2",
    "osd.5": "18.2.2",
    "osd.6": "18.2.2",
    "osd.7": "18.2.2",
    "osd.8": "18.2.2",
    "osd.9": "18.2.2"
}

4.3 JSON 解析技巧：从原始输出到可执行清单

手工逐行扫描 JSON 效率低下，尤其在大型集群中。以下提供三个实用解析方法，可直接在 Rook 工具箱或 Linux 主机上执行。

4.3.1 使用 jq 提取漂移 OSD 列表

# 提取所有版本号不等于 "18.2.2" 的 OSD ID
ceph osd versions | jq -r 'to_entries[] | select(.value != "18.2.2") | .key'

输出示例：

osd.3

4.3.2 统计各版本 OSD 数量

ceph osd versions | jq -r '[.[]] | group_by(.)[] | {version: .[0], count: length}'

输出示例：

{
  "version": "18.2.0",
  "count": 1
}
{
  "version": "18.2.2",
  "count": 9
}

4.3.3 生成校准操作清单

将漂移 OSD 列表直接转换为 ceph orch osd rm 或 kubectl delete pod 的输入：

# 生成待重建 OSD 的 Pod 名称列表（Rook 环境）
ceph osd versions | jq -r 'to_entries[] | select(.value != "18.2.2") | .key' | \
while read osd_id; do
    echo "rook-ceph-osd-${osd_id#osd.}"
done

输出示例：

rook-ceph-osd-3

4.4 版本漂移检测流程总览

以下 SVG 图展示了从命令执行到校准操作的标准检测链路：

4.5 版本分布信息对比

下表总结了两个命令的差异与适用场景：