Rook-Ceph对象存储服务部署问题排查与解决指南

问题背景

在Kubernetes环境中使用Rook-Ceph部署对象存储服务时，管理员可能会遇到对象存储服务无法正常提供的问题。本文详细记录了一个典型故障案例的分析过程和解决方案，帮助用户理解Rook-Ceph对象存储服务的工作原理和常见问题排查方法。

故障现象

在部署CephObjectStore后，系统出现以下异常情况：

1. 初始阶段出现RGW服务连接超时错误
2. 服务可达后，持续出现"NoSuchBucket"错误循环
3. COSI用户创建失败，导致对象存储无法完成协调过程
4. 对象存储桶(OBC)创建请求失败

环境信息

• Kubernetes版本：v1.28.2
• Rook版本：v1.15.6（后升级至v1.15.7）
• Ceph版本：v18.2.4 (reef)
• 操作系统：Debian with Linux 5.10.0-26-amd64
• 集群类型：本地Kubernetes集群

问题分析过程

初步排查

通过检查Rook操作日志，发现以下关键错误信息：

1. COSI用户获取失败，返回404状态码
2. 错误信息中意外出现"NoSuchBucket"提示
3. RGW服务虽然运行，但无法完成管理操作

深入调查

1. COSI用户验证：

   • 手动创建COSI用户后问题依旧
   • 确认rgw-admin-ops-user用户存在且权限配置正确

2. RGW日志分析：

   • 发现GET /admin/user请求被错误解释为s3:get_obj请求
   • 权限初始化阶段失败(init permissions failed)

3. 配置检查：

   • 确认rgw_enable_apis包含admin接口
   • rgw_admin_entry配置为默认值"admin"

关键发现

通过详细检查Ceph配置，发现全局配置中存在异常项：

rgw_dns_name rook-ceph-rgw-ceph-objectstore

此配置项导致RGW服务将管理API请求错误地解释为普通S3对象请求，从而引发后续一系列问题。

解决方案

执行以下步骤解决问题：

1. 删除异常的全局配置项：

ceph config rm global rgw_dns_name

2. 重启相关服务组件：

kubectl delete pod -n rook-ceph -l app=rook-ceph-operator
kubectl delete pod -n rook-ceph -l rgw=my-store

3. 验证修复效果：
   • 确认对象存储服务能够正常启动
   • 验证OBC创建功能恢复正常
   • 检查Ceph Dashboard显示正常

技术要点总结

1. rgw_dns_name配置：

   • 该配置通常用于虚拟主机风格的桶访问
   • 不正确的配置会导致API路由异常
   • Rook提供了专门的hosting配置项来管理此类需求

2. RGW服务管理API：

   • 管理API(/admin)需要明确启用
   • 请求路由依赖正确的配置
   • 日志中的HTTP状态码是重要诊断依据

3. 问题排查方法论：

   • 从操作日志入手，定位异常点
   • 逐层检查相关组件状态
   • 对比预期与实际行为差异

最佳实践建议

1. 生产环境中谨慎使用全局Ceph配置项
2. 使用Rook提供的原生配置方式管理RGW特性
3. 重要变更前做好配置备份
4. 保持组件版本兼容性
5. 监控PG数量和集群健康状态

后续改进

1. 考虑在Rook中增加对异常配置的检测和告警
2. 完善文档中关于rgw_dns_name配置的注意事项
3. 优化错误信息，使其更具指向性

通过本案例的分析和解决，我们不仅解决了具体的技术问题，更重要的是建立了对Rook-Ceph对象存储服务更深层次的理解，为后续的运维工作积累了宝贵经验。