云原生存储解决方案 Rook-Ceph 与 Rainbond 的结合实践-1。云原生时代的存储选择之路

最近几年，我的工作内容始终围绕着客户 Kubernetes 集群的建设。如何为客户的 Kubernetes 集群选择一款稳定可靠、性能表现优异的存储解决方案，这样的问题一直困扰着我。

存储卷可以在 Pod 漂移到其他节点后重新挂载这一最基础的功能性要求，让我一开始就把目光放在了共享文件系统这一存储类型上。最开始选择了 Nfs，到后来又投入了 Glusterfs 的怀抱，直到最近开始努力探索其他更好的云原生存储解决方案，这一路走来也让我对各种存储有了一定的了解。它们各自有着自己的特点：

• Nfs：Nfs 是一种老牌的基于网络共享文件的存储解决方案。它的优点是简单高效。它的缺点也比较明显，服务端单点故障，数据没有复制机制。在某些对可靠性要求不高的场景下，Nfs依然是不二之选。
  
• Glusterfs：这是一种开源的分布式共享存储解决方案。相对于 Nfs 而言，Gfs 通过多副本复制集提升了数据的可靠性，添加 Brick 的机制也让存储集群的扩展不再受限于一台服务器。Gfs 一度是我部在生产环境下的首选，通过将复制因子设置为 3 ，保障了数据的可靠性的同时，又能够避免分布式系统下的数据脑裂的问题。伴随 Gfs 一起前进了很久之后，我们也发现了它在密集小文件读写场景下的性能短板。而且单一的共享文件系统类型的存储，也渐渐不再满足我们的使用场景需要。
  

我们在寻找更合适的存储这一道路上一直没有停止探索。这两年云原生概念炙手可热，社区中不断涌现出来各种云原生领域项目，其中也不乏存储相关的项目。最开始，我们将目光放在 Ceph 身上，它最吸引我们的是可以提供高性能的块设备类型存储。然而被其复杂的部署方式、较高的运维门槛一度劝退。而 CNCF 毕业项目 Rook 的出现，终于铲平了接触 Ceph 的最后一道门槛。

Rook 项目提供了一种云原生存储编排工具，为各种类型的存储提供平台级、框架级的支持，统管了存储软件的安装、运维。Rook 在 2018 年发布的 0.9 版本中，正式将 Ceph Operator 作为稳定支持的特性，迄今已经数年。使用 Rook 部署和管理生产级别的 Ceph 集群还是非常稳健的。

相对于 Gfs ，Rook-Ceph 提供了性能极高的块设备类型存储，这相当于为 Pod 挂载了一块硬盘，应对密集小文件读写场景并非难事。Rook-Ceph 除了能够提供块设备类型存储之外，也可以基于 Cephfs 提供分布式共享存储，以及基于 S3 协议的对象存储。多种存储类型统一管理，并提供了可视化管理界面，对于运维人员非常友好。

作为 CNCF 毕业项目，Rook-Ceph 对云原生场景的支持毋庸置疑。部署完成的 Rook-Ceph 集群提供了 CSI 插件，以 StorageClass 的形式面向 Kubernetes 供应数据卷，对于兼容 CSI 规范的各类云原生 PaaS 平台也非常友好。