云原生存储实战：定制化Rook镜像部署与运维指南

1. 项目概述：一个面向云原生存储的Rook项目镜像

在云原生技术栈里，存储一直是个既基础又复杂的话题。我们常说“无状态应用易，有状态应用难”，这个“难”很大程度上就难在存储上。Kubernetes本身提供了基础的卷管理能力，但对于生产级的分布式存储需求——比如数据高可用、自动扩缩容、备份恢复、多副本一致性——就显得力不从心了。这时候，像Rook这样的云原生存储编排器就成了关键组件。

“Atum246/rook”这个项目标题，初看可能有点让人摸不着头脑。它不像一个标准的GitHub仓库名（比如rook/rook），更像是一个个人或特定组织维护的Docker镜像。Atum246很可能是一个Docker Hub或其它容器仓库的用户名或组织名，而rook则明确指向了Rook这个项目。简单来说，这很可能是一个由Atum246维护的、针对Rook项目的定制化或优化版的容器镜像。

对于正在或计划在Kubernetes上部署Ceph、Cassandra、NFS等存储服务的工程师来说，找到一个稳定、可靠、且可能包含特定优化或补丁的Rook镜像，是确保存储基础设施稳健的第一步。这个镜像可能解决了官方镜像在某些特定环境（比如特定CPU架构ARM、国内网络环境）下的拉取问题，或者集成了某些运维脚本、监控代理，甚至只是提供了一个版本更清晰、标签管理更规范的镜像源。接下来，我们就深入拆解一下，围绕这样一个镜像，我们需要关注哪些核心环节，以及如何安全、高效地利用它来搭建云原生存储能力。

2. 核心需求解析：为什么需要定制化的Rook镜像？

在直接使用quay.io/rook/ceph这类官方镜像看似更方便的背景下，为什么还会有Atum246/rook这样的镜像存在？这背后反映了几个在真实生产环境中无法回避的刚性需求。

2.1 网络可达性与镜像拉取速度

这是最普遍、也最直接的需求。官方镜像仓库（如quay.io,gcr.io,k8s.gcr.io）对于国内用户而言，拉取速度慢、甚至间歇性不可访问是常态。这会导致Kubernetes Pod启动失败，整个存储集群的部署流程卡在镜像拉取阶段。一个托管在国内主流容器镜像服务（如阿里云容器镜像服务ACR、腾讯云TCR、华为云SWR）或者自有镜像仓库下的镜像，能极大提升部署效率和成功率。Atum246/rook很可能就是这样一个位于更友好网络环境中的镜像源。

2.2 特定环境适配与构建优化

官方镜像是面向通用场景构建的，但我们的生产环境可能有其特殊性。例如：

• CPU架构：生产环境可能是ARM64（如鲲鹏、AWS Graviton）与AMD64混合集群。官方镜像可能只提供amd64架构，而定制镜像可以同时提供多架构支持（Multi-arch），通过docker manifest让Kubelet自动拉取匹配的镜像。
• 基础镜像安全：出于安全合规要求，企业可能需要基于特定的、经过安全扫描的基础镜像（如distroless、alpine或内部定制的OS镜像）来重建Rook组件。Atum246/rook可能使用了更小、更安全的基础镜像。
• 依赖库版本：为了修复某个特定CVE漏洞，或者与底层操作系统版本兼容，可能需要更新镜像内的某些系统库（如glibc,openssl）。定制镜像可以提前完成这些加固工作。

2.3 集成与运维增强

一个“开箱即用”程度更高的镜像能降低运维复杂度。这个定制镜像可能预置了以下内容：

• 常用工具集成：在rook-ceph-tools这类工具箱镜像中，除了标准的ceph命令，还可能预装了rbd,cephfs的管理客户端、s3cmd等，方便运维。
• 监控代理：可能集成了Prometheus node_exporter的边车（sidecar），或者暴露了更丰富的、符合特定监控体系要求的指标。
• 特定的配置预设：例如，针对国内网络环境优化了Ceph的默认配置，或者设置了更适合中小规模集群的PG（Placement Group）数计算规则。

注意：使用非官方镜像时，安全是首要考量。务必确认镜像来源的可信度，检查镜像的构建历史和Dockerfile，有条件的话应进行安全扫描。对于Atum246这类未知来源，最稳妥的方式是将其作为参考，在自己的可控环境内重新构建镜像。

3. 镜像使用与部署实操全流程

假设我们经过评估，决定尝试使用Atum246/rook这个镜像源来部署一个Ceph集群。下面是一个从零开始的完整实操流程，其中会穿插关键配置的解析和避坑点。

3.1 前置环境准备与检查

部署前，一个稳定的基础环境比什么都重要。很多人部署失败，问题都出在前期准备不足。

1. Kubernetes集群：需要一个至少三个节点（1个Master，2个Worker）的集群。生产环境建议三个Worker节点以上，且节点配置（CPU、内存、磁盘）尽量均衡。确保kubectl可以正常访问集群。
2. 裸磁盘设备：这是为Ceph OSD（对象存储守护进程）准备的。每个Worker节点上需要至少一块未分区、未挂载、未创建文件系统的空白磁盘（如/dev/sdb,/dev/nvme0n1）。使用lsblk -f命令确认磁盘状态。如果使用云盘，需要先卸载并清除文件系统签名。
3. 网络与DNS：确保集群内Pod间网络互通，且DNS解析正常。Rook Ceph的各个组件（Mon、Mgr、OSD）之间需要稳定的网络通信。Calico、Flannel等主流CNI插件一般没问题，但要避免网络策略过于严格导致组件间无法发现。
4. StorageClass准备：部署Rook Operator本身不需要特定的StorageClass，但后续创建CephCluster资源时，Operator需要为自身的Pod（如Mon Pod）创建PVC。因此，集群需要有一个默认的StorageClass，或者你需要在部署清单中显式指定一个可用的StorageClass。

3.2 部署Rook Operator（使用定制镜像）

Rook Operator是整个存储集群的大脑，负责监听CRD（自定义资源）并创建和管理实际的存储服务Pod。我们将修改官方部署清单，将其中的镜像指向Atum246/rook。

首先，获取官方部署清单。这里以Rook v1.14.0（一个较新且稳定的版本）为例：

# 下载Operator部署清单 curl -LO https://raw.githubusercontent.com/rook/rook/v1.14.0/deploy/examples/operator.yaml

接下来，编辑operator.yaml文件。我们需要修改其中所有image:字段，将quay.io/rook/ceph替换为我们的镜像地址。假设Atum246在Docker Hub上，那么镜像地址就是docker.io/atum246/rook。但更常见的是，维护者可能会在镜像名中带上后缀，如atum246/rook-ceph。这里存在一个关键点：Rook项目有多个组件镜像，最主要的是rook/ceph（用于运行Ceph守护进程），还有ceph/ceph（Ceph基础镜像）。一个负责任的定制镜像仓库，应该同时提供这两个镜像的同步或构建。

因此，我们需要在operator.yaml中全局替换：

• 将quay.io/rook/ceph:v1.14.0替换为docker.io/atum246/rook-ceph:v1.14.0
• 同时，也要找到ROOK_CEPH_IMAGE这个环境变量（通常在Deployment的env中），将其值也改为对应的ceph/ceph镜像地址，例如docker.io/atum246/ceph:v18.2.0（Ceph Quincy版本）。

修改完成后，应用这个清单：

kubectl apply -f operator.yaml -n rook-ceph

使用kubectl get pods -n rook-ceph -w观察Operator Pod的状态，直到其变为Running。如果镜像拉取失败，请检查镜像地址是否正确，以及网络是否通畅。

3.3 创建Ceph集群（核心配置解析）

Operator运行成功后，就可以创建Ceph集群了。这是最核心的一步，配置文件决定了集群的拓扑、性能和可靠性。

1. 获取集群配置清单：

   curl -LO https://raw.githubusercontent.com/rook/rook/v1.14.0/deploy/examples/cluster.yaml

2. 关键配置修改与解析：

   • dataDirHostPath：指定主机上的一个路径，用于存储Mon的映射和密钥等关键数据。即使Pod被重建，数据也不会丢失。通常设置为/var/lib/rook。确保所有节点都存在此目录且有写入权限。
   • storage配置段：这是定义存储资源的核心。

     storage: useAllNodes: false # 不要使用所有节点，建议显式指定 useAllDevices: false # 不要使用所有设备，非常危险！ nodes: - name: "node1" # 你的节点名称，通过 `kubectl get nodes` 获取 devices: - name: "sdb" # 节点上准备好的裸设备名 - name: "node2" devices: - name: "sdb" - name: "node3" devices: - name: "sdb"

     为什么显式指定？useAllNodes: true和useAllDevices: true看似方便，但会扫描所有节点和所有磁盘，极易误将系统盘或数据盘初始化为OSD，导致灾难性数据丢失。生产环境必须禁用。
   • mon配置：Mon（Monitor）负责维护集群映射。count建议为奇数（1,3,5），通常3个即可提供高可用。要确保count不大于你提供的存储节点数。
   • cephVersion：这里需要和Operator中ROOK_CEPH_IMAGE环境变量指定的Ceph版本一致。例如：

     cephVersion: image: docker.io/atum246/ceph:v18.2.0 # 必须与Operator中的Ceph镜像一致 allowUnsupported: false

3. 应用集群配置：

   kubectl apply -f cluster.yaml -n rook-ceph

   这个过程会比较长（可能10-30分钟），因为Rook要在每个节点上创建OSD Pod，并初始化Ceph集群。可以通过以下命令观察进度：

   # 查看所有Pod状态 kubectl get pods -n rook-ceph # 查看集群健康状态 kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph status # 查看OSD部署情况 kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph osd tree

   当ceph status输出显示health: HEALTH_OK时，恭喜你，一个基于定制镜像的Ceph集群就部署成功了。

4. 存储供给与应用对接实战

集群建好是第一步，接下来要让应用能用上这个存储。Rook通过创建StorageClass来动态供给PV（持久卷）。

4.1 创建块存储（RBD）供有状态应用使用

块存储类似于虚拟硬盘，适合数据库（如MySQL、PostgreSQL）、消息队列等需要直接访问块设备的应用。

1. 创建StorageClass：

   curl -LO https://raw.githubusercontent.com/rook/rook/v1.14.0/deploy/examples/csi/rbd/storageclass.yaml

   这个文件定义了一个名为rook-ceph-block的StorageClass。其provisioner是rook-ceph.rbd.csi.ceph.com，这是Rook提供的CSI驱动。你可以根据需要修改pool（默认为replicapool），以及parameters中的clusterID（默认为rook-ceph）等参数。通常默认即可。

   kubectl apply -f storageclass.yaml

2. 应用中使用PVC： 在你的应用部署清单（如deployment.yaml或statefulset.yaml）中，定义PVC并引用这个StorageClass。

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: storageClassName: rook-ceph-block # 这里对应上面创建的SC accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

   当应用Pod被调度时，Rook CSI驱动会自动在Ceph集群中创建一个RBD镜像，并为其创建PV，然后绑定到PVC上。

4.2 创建共享文件存储（CephFS）供多Pod读写

文件存储类似于网络文件系统（NFS），适合内容管理系统、共享配置文件、日志聚合等需要多Pod共享读写的场景。

1. 创建CephFS文件系统：

   curl -LO https://raw.githubusercontent.com/rook/rook/v1.14.0/deploy/examples/filesystem.yaml kubectl apply -f filesystem.yaml -n rook-ceph

   这会创建两个Ceph存储池（data和metadata）和一个MDS（元数据服务器）实例。

2. 创建对应的StorageClass：

   curl -LO https://raw.githubusercontent.com/rook/rook/v1.14.0/deploy/examples/csi/cephfs/storageclass.yaml

   修改storageclass.yaml，确保clusterID和fsName（默认为myfs）与上一步创建的资源匹配。

   kubectl apply -f storageclass.yaml

3. 应用中使用：在PVC中指定storageClassName为这个新建的CephFS StorageClass即可，且accessModes可以设置为ReadWriteMany。

5. 运维、监控与故障排查实录

存储集群上线后，稳定运维和快速排障是关键。以下是我在实际运维中积累的一些核心经验和常见问题。

5.1 集群健康监控与日常检查

不要等到报警才发现问题。建立日常检查清单：

• 每日快速检查：

  # 进入工具箱Pod kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash # 检查集群健康状态（最核心） ceph status # 检查OSD状态，确保所有OSD都是 up 且 in ceph osd stat ceph osd tree # 检查Mon仲裁状态 ceph quorum_status # 检查存储池使用率和PG状态 ceph df ceph pg stat

• 设置Prometheus监控：强烈建议部署Rook提供的Prometheus规则和Grafana仪表板。它能监控集群容量、性能、OSD状态、PG异常等几乎所有指标，是 proactive运维的利器。

5.2 常见故障与排查思路

1. OSD启动失败（CrashLoopBackOff）

   • 现象：kubectl get pods -n rook-ceph发现某个rook-ceph-osdPod反复重启。
   • 排查：
     • kubectl logs -n rook-ceph <osd-pod-name> --previous查看上一个容器的日志，通常有错误信息。
     • 常见原因1：磁盘问题。日志中可能有“bluestore could not find device”或权限错误。登录对应节点，检查/dev/下对应的磁盘设备是否存在，权限是否为ceph:ceph。使用lsblk确认磁盘未被其他进程占用。
     • 常见原因2：资源不足。OSD默认需要较多内存。检查节点内存是否充足，或考虑通过rook-ceph-operator-configConfigMap调整OSD的内存限制。
     • 常见原因3：内核版本或模块问题。Ceph对内核版本有一定要求。确保节点内核版本不是太旧，且rbd、ceph等内核模块已加载。

2. PVC一直处于Pending状态

   • 现象：应用Pod卡住，PVC状态为Pending。
   • 排查：
     • kubectl describe pvc <pvc-name>查看事件。最常见的原因是StorageClass配置错误或Provisioner（CSI驱动）有问题。
     • 检查StorageClass：kubectl get storageclass rook-ceph-block -o yaml，确认provisioner字段正确，且parameters中的clusterID、pool名称与Ceph集群内实际信息一致。
     • 检查CSI驱动Pod：kubectl get pods -n rook-ceph -l app=csi-rbd-plugin或-l app=csi-cephfs-plugin，确保这些Pod是Running状态。查看它们的日志以获取更详细的错误。

3. 集群健康状态为 HEALTH_WARN 或 HEALTH_ERR

   • 现象：ceph status显示非HEALTH_OK状态。
   • 排查：ceph health detail会给出详细警告信息。
     • too few PGs per OSD：这是最常见的警告。PG（归置组）是Ceph数据分布的单位。PG数量不足会影响数据平衡和性能。需要根据集群规模和存储池配置调整PG数量。可以使用Rook提供的pg-autoscaler功能，或手动计算后调整。
     • slow ops：有慢操作。可能是磁盘IO性能瓶颈、网络延迟或Mon负载过高。结合ceph osd perf和ceph mon stat进一步分析。
     • clock skew：节点间时钟不同步。这是严重问题，会导致数据不一致！必须在所有节点部署NTP服务并确保时钟同步。

5.3 数据安全与备份考量

• 定期备份CRD资源：Rook集群的所有配置（CephCluster、CephBlockPool、CephFilesystem等）都保存在Kubernetes的CRD中。定期使用kubectl get -n rook-ceph <crd-kind> -o yaml > backup.yaml进行备份，在集群灾难恢复时至关重要。
• Ceph集群数据备份：对于存储池内的数据，可以考虑使用rbd或cephfs的快照功能，或者使用velero这类Kubernetes原生备份工具，配合Rook的CSI快照能力进行应用一致性备份。
• 谨慎操作：在Ceph集群中执行ceph osd out、ceph osd crush reweight等重量级命令前，务必明确其后果，最好在测试环境验证。

6. 镜像构建与维护进阶指南

如果你不满足于直接使用他人的镜像，或者出于安全合规要求，需要自己构建和维护Rook镜像，那么你需要了解以下流程。

6.1 构建自定义的Rook镜像

核心是获取Rook的官方Dockerfile，并在可控环境下构建。

1. 获取源码和构建上下文：

   git clone --branch v1.14.0 https://github.com/rook/rook.git cd rook/images/ceph

   这个目录下包含了构建rook/ceph镜像所需的Dockerfile和脚本。

2. 修改与构建：

   • 你可以编辑Dockerfile，更换基础镜像（如使用ubi8/ubi-minimal以获得更好的RedHat生态兼容性），或者增加一些必要的运维工具包。
   • 执行构建（需要Docker或Buildah）：

     # 假设你使用Docker，并想构建多架构镜像 docker buildx create --use docker buildx build --platform linux/amd64,linux/arm64 -t your-registry/your-org/rook-ceph:v1.14.0-custom --push .

   构建ceph/ceph镜像的过程类似，但通常更复杂，因为它需要从Ceph源码编译。更常见的做法是直接从官方镜像仓库同步到私有仓库，或者使用官方发布的二进制包制作镜像。

6.2 建立内部的镜像同步与更新流程

对于生产环境，建议建立自动化的镜像同步管道。

1. 镜像仓库选择：使用企业内部的私有容器镜像仓库（Harbor, Nexus, ACR企业版等）。
2. 同步策略：
   • 定期同步：使用工具（如skopeo,crane）编写脚本，定期将quay.io/rook/ceph:v1.14.0和quay.io/ceph/ceph:v18.2.0同步到内部仓库。
   • 触发式构建：在GitHub上Watch Rook项目的Release，当有新版本发布时，通过Webhook触发CI/CD流水线，自动拉取新版本代码，构建并测试自定义镜像，然后推送到内部仓库。
3. 版本标签管理：除了官方版本号（如v1.14.0），建议添加构建日期或内部版本号标签，如v1.14.0-b20240527，便于追溯和回滚。

自己维护镜像增加了工作量，但也带来了最大的可控性和安全性。你需要权衡团队的技术能力和运维成本。对于大多数团队，从可信的第三方镜像源（如各大云厂商提供的镜像加速地址）拉取，可能是性价比更高的选择。而像“Atum246/rook”这样的项目，其价值就在于为社区提供了一个可能更便捷的选择，但在采用前，务必做好充分的验证和测试。