Rook Ceph OSD 内存泄漏问题分析与解决方案

问题背景

在Rook Ceph存储集群中，当尝试为新增磁盘配置OSD时，系统出现了严重的内存泄漏问题。具体表现为/rook/rook ceph osd provision进程持续消耗内存，最终导致系统触发OOM Killer机制终止进程。该问题发生在Ubuntu 22.04系统上，使用Rook v1.14.0和Ceph 18.2.2版本。

问题现象

在添加新磁盘（1.8TB和3.6TB各一块）后，系统启动k8s作业准备服务器并发现新磁盘。随后启动的/rook/rook ceph osd provision进程开始异常消耗内存：

• 内存消耗持续增长，最终达到117GB以上
• 系统64GB物理内存和64GB交换空间全部耗尽
• 进程CPU占用率约10%
• 磁盘I/O活动异常低，与预期的大规模磁盘写入不符

根本原因分析

通过深入排查发现，问题的根源在于Ceph认证系统中残留的OSD密钥与新OSD创建过程发生冲突：

1. 残留密钥问题：系统中存在一个已删除OSD（osd.21）的认证密钥未被清除
2. 创建冲突：当尝试为新磁盘创建OSD时，系统试图重用osd.21 ID，但因密钥不匹配而失败
3. 异常处理缺失：/rook/rook ceph osd provision进程未能正确处理创建失败的情况，导致内存持续增长

解决方案

1. 手动清理残留密钥：

   ceph auth rm osd.21
   

2. 终止异常进程：强制终止内存泄漏的rook进程，让k8s自动重启作业

3. 验证解决效果：重启后OSD创建过程恢复正常，内存使用保持稳定

最佳实践建议

1. OSD清理流程：确保使用完整清理流程移除OSD，包括认证密钥
2. 监控机制：对OSD准备过程实施内存使用监控
3. 错误处理：改进rook代码中对ceph-volume命令失败的处理逻辑
4. 集群健康检查：在添加新OSD前确认集群状态完全健康

技术深度解析

该问题揭示了Rook Ceph在OSD管理中的几个关键点：

1. ID重用机制：Ceph会尝试重用已删除OSD的ID，这对资源回收有利但需要完善的清理机制
2. 认证系统一致性：残留的认证密钥可能导致各种不可预知的问题
3. 进程健壮性：长时间运行的后台进程必须具备完善的内存管理和错误恢复机制

总结

这一案例展示了分布式存储系统中资源管理复杂性的一个典型例子。通过分析我们了解到，即使是看似简单的磁盘添加操作，也可能因为系统状态不一致而引发严重问题。运维人员应当建立完善的监控体系，并对系统各组件的交互机制有深入理解，才能快速定位和解决此类问题。