在Kubernetes环境中，使用NFS作为存储方案存在单点故障风险，难以满足生产环境的高可用需求。Ceph作为成熟的企业级分布式存储系统，是理想的替代方案。本文将深入探讨如何通过CSI（容器存储接口）标准，让Ceph为K8s提供稳定、高效的存储服务，并详解RBD与CephFS两种核心模式的选择与应用。
智能速览
传统的In-tree存储插件因与K8s紧耦合已被废弃，CSI成为主流标准。
CSI实现了K8s与存储系统的解耦，允许两者独立升级与演进。
Ceph-CSI主要提供RBD（块存储）和CephFS（文件存储）两种模式。
RBD模式提供高性能独享访问，适用于数据库等ReadWriteOnce场景。
CephFS模式支持多节点共享读写，适用于Web服务日志等ReadWriteMany场景。
整个存储申请流程由Pod发起，经由PVC、StorageClass和CSI驱动，最终由Ceph集群响应。
精华内容
理解了为何要选择Ceph之后，关键问题便成了如何让Kubernetes与Ceph高效协作。从过去的紧耦合到如今的标准化接口，这套方案的演进彻底改变了云原生存储的游戏规则。
旧时代的局限
早期Kubernetes集成Ceph的方式是In-tree插件，即将Ceph的连接代码直接编译进K8s核心代码。这种方式存在致命缺陷：一旦Ceph发布新版本或修复Bug，用户必须等待K8s同步发布新版本才能应用更新。这种强绑定关系严重限制了运维的灵活性和系统的稳定性，因此已被官方废弃，不应在新项目中采用。
CSI：解耦的艺术
CSI（容器存储接口）的出现解决了上述难题。它定义了一套通用的存储接口标准，K8s只需按这套标准发出指令，如“创建一个10GB的存储卷”。具体的实现则由各存储厂商（如Ceph）提供的独立CSI驱动程序负责。Ceph-CSI驱动接收K8s指令后，将其翻译成Ceph集群能理解的语言并执行。这种设计实现了K8s与Ceph的完美解耦，双方可以独立升级，互不影响，极大地提升了系统的可维护性。
RBD：为性能而生
Ceph在K8s中主要通过RBD提供块存储服务。RBD模式将Ceph集群中的一块存储空间虚拟成一个块设备，然后挂载给单个Pod使用。这种模式对应K8s的ReadWriteOnce（RWO）访问模式，意味着一个存储卷在同一时间只能被一个节点挂载写入。
其优势在于性能出色，接近本地磁盘的I/O表现，非常适合对性能和独占性要求高的应用，如数据库（MySQL、PostgreSQL）、消息队列（Kafka、RabbitMQ）等。需要注意的是，RBD本身不支持跨节点的并发读写，但借助K8s的Attach/Detach机制，当Pod漂移到新节点时，存储卷可以被重新挂载。
CephFS：共享的便捷
当需要多个Pod同时读写同一个目录时，CephFS文件存储便成为最佳选择。CephFS模式在K8s中对应ReadWriteMany（RWX）访问模式，其工作方式类似于传统的NFS，允许多个节点上的多个Pod同时挂载并访问同一文件系统。
这种共享特性使其适用于多种场景，例如：多个Web服务器实例共享静态资源文件、CI/CD流水线中的共享构建空间、以及集中收集多个应用节点的日志文件。虽然CephFS的性能在极端高并发场景下可能略低于RBD，但其提供的灵活性和共享能力是RBD无法替代的。
工作流一览
整个存储供给过程自动化且清晰。首先，开发者在Pod定义中声明需要一个PVC（PersistentVolumeClaim）来申请存储。这个PVC会关联一个预先定义好的StorageClass对象，该对象指定了使用哪个CSI驱动（如Ceph-CSI）以及存储的参数（如副本数、存储池等）。
随后，K8s的存储控制器根据PVC和StorageClass的信息，调用相应的Ceph-CSI驱动。CSI驱动负责与Ceph集群通信，执行创建RBD镜像或CephFS文件系统等实际操作，并将创建好的存储卷挂载到目标Pod中，整个过程对用户透明。
