如何安全高效对接外部Ceph集群？

Kubernetes生产实战：如何安全高效对接外部Ceph集群？

在金融级容器化改造中，我们曾因直接使用CephFS导致集群雪崩。血的教训告诉我们：对接外部Ceph绝非改个StorageClass那么简单。本文将分享经过20+生产集群验证的外部Ceph对接方案，带您避开那些藏在细节里的"魔鬼"。

---

一、对接方案全景图

1.1 两种主流方案对比

维度	传统RBD对接	CSI驱动方案
兼容性	Kubernetes 1.20前主流	1.13+推荐方案
功能支持	基础块存储	支持快照/克隆/扩容
鉴权方式	共享admin密钥风险高	支持按命名空间隔离密钥
升级维护	需重启kubelet	独立组件热升级
性能损耗	15%-20%	5%-8%（内核直通）

生产建议：新集群一律采用CSI方案，已有集群逐步迁移

1.2 网络拓扑规划

• 隔离网络：Ceph集群与K8s工作节点需万兆互联
• 防火墙策略：开放6789(TCP)、6800-7300(TCP)端口
• 多Monitor配置：至少3个非K8s节点部署MON服务

---

二、CSI方案实施详解

2.1 密钥安全管理

# 创建受限权限用户（非admin！）
ceph auth get-or-create client.k8s \
 mon 'allow r' \
 osd 'allow rwx pool=k8s-data'

# 生成K8s Secret
kubectl create secret generic ceph-csi-k8s-secret \
--from-literal=userID=k8s \
--from-literal=userKey=AQCvCqZeAAAAABAAZ1Qx8M8IMJSP4RhTO0Jk3Q== \
-n ceph-csi

2.2 CSI驱动部署

# csi-config-map.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: ceph-csi-config
data:
  config.json: |-
    [
      {
        "clusterID": "cluster01",
        "monitors": [
          "10.0.0.1:6789",
          "10.0.0.2:6789",
          "10.0.0.3:6789"
        ]
      }
    ]

2.3 StorageClass配置

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd
provisioner: rbd.csi.ceph.com
parameters:
  clusterID: cluster01
  pool: k8s-data
  imageFeatures: layering,exclusive-lock
  csi.storage.k8s.io/provisioner-secret-name: ceph-csi-k8s-secret
  csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi
  csi.storage.k8s.io/node-stage-secret-name: ceph-csi-k8s-secret
  csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - discard  # 优化SSD性能

---

三、生产环境调优指南

3.1 内核参数优化

# 调整网络参数
sysctl -w net.core.rmem_max=268435456
sysctl -w net.core.wmem_max=268435456

# 块设备队列优化
echo 4096 > /sys/block/rbd0/queue/nr_requests
echo "deadline" > /sys/block/rbd0/queue/scheduler

3.2 CSI驱动参数

# csi-rbd-plugin.yaml
args:
  - "--worker-threads=20"          # 根据CPU核数调整
  - "--client-mount-timeout=300"    # 超时时间延长
  - "--enable-pprof=true"           # 开启性能分析
env:
  - name: CSI_ENABLE_GRPC_METRICS
    value: "true"

3.3 多层级存储池配置

# 创建缓存池
ceph osd tier add k8s-data cache-pool
ceph osd tier cache-mode cache-pool writeback
ceph osd tier set-overlay k8s-data cache-pool

# 设置缓存策略
ceph osd pool set cache-pool hit_set_count 8
ceph osd pool set cache-pool hit_set_period 600

---

四、监控告警体系建设

4.1 Prometheus指标采集

# ceph-service-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: ceph-monitor
spec:
  endpoints:
  - port: http-metrics
    interval: 30s
  selector:
    matchLabels:
      app: ceph-exporter

4.2 关键告警规则

- alert: CephOSDNearFull
  expr: ceph_osd_utilization > 85
  for: 15m
  labels:
    severity: critical
  annotations:
    summary: "Ceph OSD {{ $labels.osd }} 使用率超过85%"

- alert: CephSlowOps
  expr: rate(ceph_osd_op_r_latency_sum[5m]) > 0.1
  for: 5m
  labels:
    severity: warning

---

五、故障排查工具箱

5.1 常见问题速查表

现象	排查命令	典型原因
PVC一直Pending	kubectl describe pvc <name>	Secret配置错误/Mon不可达
挂载超时	`dmesg	grep rbd`
IO性能骤降	ceph osd perf	网络抖动/OSD故障
卷无法删除	rbd ls -p k8s-data	残留快照/镜像锁未释放

5.2 诊断流程示例

# 查看CSI驱动日志
kubectl logs -n ceph-csi csi-rbdplugin-provisioner-0 -c csi-rbdplugin

# 检查RBD镜像状态
rbd info k8s-data/csi-vol-xxxxxx
rbd status k8s-data/csi-vol-xxxxxx

# 追踪内核操作
strace -p $(pgrep rbd) -e trace=file

---

六、避坑指南：血泪教训总结

6.1 密钥管理雷区

事故案例：使用admin密钥导致Ceph集群被误删
正确姿势：

• 为K8s创建专用受限账户
• 定期轮转密钥（每90天）
• 通过Vault动态管理密钥

6.2 版本兼容陷阱

致命组合：

• Kubernetes 1.18 + Ceph Nautilus + CSI 3.2
  推荐矩阵：
  | Kubernetes | Ceph版本 | CSI驱动版本 |
  |------------|-----------|------------|
  | 1.20+ | Quincy | 3.5+ |
  | 1.18-1.19 | Pacific | 3.2 |

6.3 容量规划误区

错误做法：存储池使用率超过70%
最佳实践：

• 设置自动扩容触发器（使用率>60%）
• 预留20%缓冲空间
• 启用自动均衡器

ceph osd set-backfillfull-ratio 0.8
ceph osd set-nearfull-ratio 0.7

---

七、未来演进方向

1. 智能QoS：基于AI预测实现动态限速
2. 跨集群容灾：结合Rook实现秒级RPO
3. Serverless存储：按需创建/销毁存储后端

经过三年生产环境锤炼，我们的方案成功支撑单集群5000+ PVC的稳定运行。记住：真正的存储对接不是让K8s能用Ceph，而是让两者像齿轮一样精密咬合。当你的Pod能在30秒内挂载1TB卷，当故障切换时间从分钟级降至秒级，这才是云原生存储应有的样子。