Ceph 19.2.6 与低版本内核的“生死劫”—— CSI 无法创建 RBD 破局指南

一、前言前段时间在测试环境部署了基于Ceph Squid 19.2.6的集群准备通过ceph-csi(rbd 驱动) 对接 K8s 动态供给 PVC。一切看起来都很顺利Ceph 集群HEALTH_OKCSI 插件的 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-announceceph.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.15Ubuntu 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占用[rootceph142 ~]# 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 [rootceph142 ~]#手动擦除磁盘数据就都没有了⚠️适用于数据不需要的场景你执行了ceph-volume lvm zap --destroy这个命令的“含金量”就在于--destroy。它的作用就是强制销毁 LVM 结构并擦除磁盘头部和尾部的签名相当于把书的目录和开头的章节全撕了。再加上之前执行过的rm-cluster --zap-osds只要这两步都走了盘上的旧 OSD 数据可以说是灰飞烟灭无法恢复了。[rootceph141 ~]# 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[rootceph141 ~]# 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对接cephpvc测试动态存储新环境准备好后配置csi驱动即可可以参考我上篇博客k8s集群通过csi对接ceph集群rbd提供动态存储pv4-CSDN博客