银河麒麟系统如何部署Rook Ceph存储operator？完整流程详解

银河麒麟作为国内信创环境里使用最广的服务器操作系统之一，基于openEuler社区版本构建，内核兼容性整体不错。在搭建Kubernetes平台后，持久化存储一直是绕不开的话题，而Rook Ceph凭借部署简单、社区活跃、功能完整的特点，成为云原生存储的首选方案。本文以银河麒麟V10 SP3为例，完整走一遍Rook operator的部署流程，并记录几个在麒麟系统上特有的坑点。

一、部署前的系统检查与内核准备

Rook Ceph对内核有一定要求，尤其是使用CephFS时需要内核支持RBD模块和Ceph协议。银河麒麟V10基于Linux 4.19或更高版本的内核，默认已经编译了rbd与libceph模块，但未必自动加载，需要手动确认：

# 检查内核模块是否加载
lsmod | grep rbd
lsmod | grep ceph

# 如果没有输出，手动加载
modprobe rbd
modprobe ceph

# 设置开机自动加载
cat <<EOF > /etc/modules-load.d/ceph.conf
rbd
ceph
EOF

如果modprobe报错说找不到模块，说明当前内核没有编译相关选项，可以执行find /lib/modules/$(uname -r) -name "*rbd*"确认ko文件是否存在。麒麟系统的kernel包一般都会带上，找不到多半是升级过内核后残留的旧目录，执行depmod -a重建依赖即可。

另一个容易被忽视的点是磁盘。Ceph的OSD守护进程要求使用裸块设备，不能是带有文件系统或分区残留的盘。麒麟系统安装时如果用图形化分区工具，可能自动给数据盘创建了LVM，需要提前清理：

# 查看数据盘情况，假设为/dev/sdb
lsblk -f /dev/sdb
wipefs -a /dev/sdb
# 如果存在LVM残留，还要删掉对应的PV
pvremove /dev/sdb1 --force 2>/dev/null || true

每个计划承载OSD的节点都要做同样的检查，否则operator部署时会卡在OSD provisioning阶段，日志里反复出现device is in use的报错。

二、部署Rook operator

准备就绪后开始安装Rook。先从官方仓库拉取release版本，国内环境如果访问GitHub受限，可以通过镜像站或者提前下载好的离线包导入。创建namespace和CRD：

git clone --single-branch --branch v1.12.10 \
  https://github.com/rook/rook.git
cd rook/deploy/examples
kubectl create -f crds.yaml -f common.yaml -f operator.yaml

# 查看operator运行状态
kubectl -n rook-ceph get pod -l app=rook-ceph-operator

这里有一个麒麟环境下的实际坑：operator默认镜像地址是quay.io，拉取速度极慢甚至失败。解决办法是修改operator.yaml里的镜像字段，换成国内可访问的镜像源，例如quay.mirrors.ghproxy.com/rook/ceph:v1.12.10，或者用docker save与skopeo把镜像同步到私有仓库。CSI相关镜像同理，集中在ROOK_CSI_REGISTRAR_IMAGE、ROOK_CSI_PROVISIONER_IMAGE等环境变量里，逐一替换。

operator起来之后，日志里看到一条关键信息就说明它已经就绪：

kubectl -n rook-ceph logs -l app=rook-ceph-operator | grep "starting Rook"

此时operator还在持续监听CRD事件，真正的Ceph集群要靠CephCluster这个自定义资源来触发创建。

三、创建CephCluster集群与存储池

官方示例里的cluster.yaml适用于host模式，生产环境建议根据机器数量调整。下面是一个经过验证的精简版配置，三个节点各贡献一块裸盘：

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v17.2.6
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  storage:
    useAllNodes: true
    useAllDevices: true
    # 更稳妥的做法是指定设备
    # deviceFilter: "^sd[b-z]"
  placement:
    osd:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists

mon的数量必须是奇数，最少1个。三节点小集群如果磁盘紧张，可以设置mon.count: 1再加stretchCluster参数保证可用性，但对于测试环境，直接3个mon是最省心的。镜像同样要替换成国内源，Ceph主体镜像 quay.io/ceph/ceph 体积超过1GB，拉取失败是部署卡住的头号原因。

提交清单后观察pod启动过程，正常顺序是mon先起来，然后是mgr，最后OSD逐个就位：

kubectl create -f cluster.yaml
kubectl -n rook-ceph get pod -w

# 全部Running后，创建工具箱验证
kubectl create -f toolbox.yaml
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph status

ceph status输出中health显示HEALTH_OK，且pgs全部active+clean，就代表集群健康。接着创建块存储供Kubernetes的PVC消费：

kubectl create -f csi/rbd/storageclass.yaml

# 快速验证
kubectl create -f filesystem-test.yaml
kubectl get pvc

四、常见问题排查思路

部署失败大多集中在三类。第一类是镜像问题，表现为pod长时间ContainerCreating，用kubectl describe pod看Events栏，出现ImagePullBackOff就逐个替换镜像源。第二类是OSD起不来，多半是磁盘没清理干净或者内核模块缺失，去operator日志里搜provision关键词能定位到具体节点和设备。

第三类是麒麟系统的SELinux策略问题。如果enforcing模式下CSI插件无法挂载卷，可以先把SELinux设为permissive观察是否恢复，确认是策略拦截后，用audit2allow生成针对性的策略模块，而不是简单粗暴地永久关闭SELinux，这样在信创安全测评时不会留尾巴：

setenforce 0
# 测试恢复后生成定制策略
ausearch -m avc -ts recent | audit2allow -M rook-csi
semodule -i rook-csi.pp
setenforce 1

最后建议部署完成后安装官方的Prometheus规则文件，把Ceph的健康状态接入监控告警，磁盘快满、PG降级这些隐患提前暴露，比事后救火轻松得多。整个流程在麒麟V10 SP3加Kubernetes v1.27的环境下验证通过，希望对做国产化云原生平台的团队有所帮助。

银河麒麟Rook CephKubernetes存储修改时间：2026-09-08 05:08:32