一、前言
📚
前段时间，在测试环境部署了基于Ceph Squid 19.2.6的集群，准备通过ceph-csi(rbd 驱动) 对接 K8s 动态供给 PVC。
一切看起来都很顺利：Ceph 集群HEALTH_OK，CSI 插件的 Pod 也都跑到了Running状态。但当我兴冲冲地创建一个测试 PVC 时，却死活处于Pending状态。
❌️
查看 Provisioner 的日志，赫然躺着一行极其抽象的报错：
rpc error: code = Internal desc = failed to get connection: connecting failed: rados: ret=-22, Invalid argument
💡
错误代码ret=-22(EINVAL)意味着“无效参数”。这通常发生在参数传递错误或底层不支持的情况下。经过漫长的排查和查阅官方邮件列表，终于揪出了幕后黑手——Ceph 19.2.6 引入的aes256k新式密钥，与低于 7.0 版本的 Linux 内核存在不可调和的兼容性冲突。
二、用户态与内核态的割裂
推荐阅读：
https://lists.ceph.io/hyperkitty/list/ceph-announce@ceph.io/thread/VCSCEMZLT7GPJXUZ7CLCLJJE5AAUQVEZ/
很多朋友可能会疑惑：我之前用 Ceph 19.2.3 甚至 18.x 配合 Ubuntu 22.04 (5.15内核) 都好好的，怎么到了 19.2.6 就不行了？
罪魁祸首是CVE-2025-30156这个安全漏洞。为了修复该漏洞，Ceph 官方在19.2.6版本中，强制将默认的 CephX 认证密钥类型从旧的aes升级到了安全性更高的aes256k。
Ceph 的架构分为两半：
控制面（用户态）：如 ceph-mon, ceph-mgr, 以及 CSI Provisioner。它们是跑在容器里的，由 Ceph 官方镜像提供，自然认识新的
aes256k密钥。数据面（内核态）：K8s 节点在挂载 RBD 卷时，依赖的是操作系统的内核模块
libceph和rbd。
问题就出在这里：Linux 上游内核对aes256k密钥的支持，是从7.0内核才开始的（并且仅针对部分发行版进行了 backport）。
当你节点上跑的还是 5.15（Ubuntu 22.04）或 4.19（银河麒麟）内核时，内核模块拿到aes256k密钥会一脸懵逼，直接拒绝连接，抛出rados: ret=-22。
更恶心的是，Ceph 19.2.6 还不允许直接创建旧式的aes密钥（会报Error EINVAL: creating key with insecure key type ("aes") not allowed），直接把退路给堵死了。
三、解决方案（回退ceph版本）
如果你的操作系统无法立刻升级到 7.0 内核，最快且最稳妥的办法就是将 Ceph 集群回退到 19.2.3 或更低版本。
注意：Ceph 不支持原地降级，必须清理集群后重新部署。
此种方案，适合ceph集群最初搭建时期，没有正式投入生产。⚠️
一、清理旧环境
1.服务清理
每个节点都需要手动执行一遍
# 1. 进入 cephadm shell cephadm shell # 2. 禁用 cephadm 编排，防止它继续拉起守护进程 ceph mgr module disable cephadm # 3. 获取当前集群的 FSID（记下来，下一步要用） ceph fsid # 4. 退出 shell exit # 5. 执行清理（将 <FSID> 替换为上一步获取的值） # 这条命令会强制删除所有守护进程，并清空 OSD 数据 cephadm rm-cluster --force --zap-osds --fsid <你的FSID>清理后，docker ps -a验证容器都删除了。
2.磁盘清理
上述操作后，磁盘还是没有释放，需要清理磁盘,（不清理磁盘的话加不到集群里面去）
查看没有清理的磁盘
磁盘已经被vg占用
[root@ceph142 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 63.8M 1 loop /snap/core20/2922 loop1 7:1 0 64M 1 loop /snap/core20/2379 loop2 7:2 0 115.2M 1 loop /snap/lxd/40911 loop3 7:3 0 40.4M 1 loop /snap/snapd/20671 loop4 7:4 0 38.8M 1 loop /snap/snapd/21759 loop5 7:5 0 74M 1 loop /snap/core22/2955 loop6 7:6 0 87M 1 loop /snap/lxd/29351 sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 98G 0 part └─ubuntu--vg-ubuntu--lv 253:4 0 49G 0 lvm / sdb 8:16 0 300G 0 disk └─ceph--01b97133--0248--4305--9209--2010a76bfedc-osd--block--69367020--7f29--442b--ba74--e4ff423389c5 253:2 0 300G 0 lvm sdc 8:32 0 500G 0 disk └─ceph--d56b0af0--6b6d--411c--8c1e--0b653b2dfb24-osd--block--9cec66da--8e0c--4510--b228--125ef8002491 253:3 0 500G 0 lvm sdd 8:48 0 1T 0 disk └─ceph--e0d1f27f--139b--47b2--bf7e--af9398d858e9-osd--block--7d6ab259--7bc3--4b67--a333--5e9e2a040a29 253:0 0 1024G 0 lvm sde 8:64 0 500G 0 disk └─ceph--6bea9e73--9edf--4d59--b6e5--f4b7f805a9c1-osd--block--a331a337--5170--451b--9b37--25c4a56578dd 253:1 0 500G 0 lvm sr0 11:0 1 1024M 0 rom [root@ceph142 ~]#手动擦除磁盘（数据就都没有了）⚠️（适用于数据不需要的场景）
你执行了ceph-volume lvm zap --destroy，这个命令的“含金量”就在于--destroy。它的作用就是强制销毁 LVM 结构，并擦除磁盘头部和尾部的签名（相当于把书的目录和开头的章节全撕了）。再加上之前执行过的rm-cluster --zap-osds，只要这两步都走了，盘上的旧 OSD 数据可以说是灰飞烟灭，无法恢复了。
[root@ceph141 ~]# ceph-volume lvm zap /dev/sdb --destroy ceph-volume lvm zap /dev/sdc --destroy ceph-volume lvm zap /dev/sdd --destroy ceph-volume lvm zap /dev/sde --destroy二、初始化19.2.3新环境
1.准备19.2.3版本镜像
2.初始化ceph集群
指定ceph版本
--image quay.io/ceph/ceph:v19.2.3
[root@ceph141 ~]# cephadm --image quay.io/ceph/ceph:v19.2.3 bootstrap \ --mon-ip 10.0.0.141 \ --cluster-network 10.0.0.0/24 \ --allow-fqdn-hostname \ --skip-pull3.后续操作在之前博客介绍过，剩余操作请参考：
使用cephadm部署ceph集群（ceph进阶之路-1.cephadm部署ceph集群）-CSDN博客
验证新集群版本
三、csi对接ceph，pvc测试动态存储
新环境准备好后，配置csi驱动即可，可以参考我上篇博客：
k8s集群通过csi对接ceph集群，rbd提供动态存储pv（4）-CSDN博客
