这篇文章上次修改于 686 天前，可能其部分内容已经发生变化，如有疑问可询问作者。

前言

对于K8s来说，高可用是其一大亮点，对于生产环境来说，无论是服务高可用还是数据高可用都是不可忽视的部分。在参考NFS、LocalEBS、GlusterFS、Ceph等存储方案后，我最终选择了使用Ceph作为集群数据持久化方案。

其他实现方式的缺陷

NFS

在K8s最近(1.20.0+)的StackoverFlow、Github issues里能经常看到关于NFS的报错，根据K8s社区测试的结果，普遍得出NFS在K8s 1.20.0+版本会出现CrashLoopBackOff的错误，其原因是NFS可能会引起 failed to obtain lock 和 input/output error 等问题，从而导致容器崩溃。
这对于生产环境服务是不可接受的。

GlusterFS

GlusterFS框架本身并不支持对外提供RESTful API，所以其RESTful API是由另一个社区项目——Heketi进行适配的。K8s经由这个项目才能以CSI的方式调用GlusterFS。
然而Heketi的项目近况并不好，在其2021年的一次更新中，README.md里提到了:

The Heketi project is now in deep maintenance status. This means that only critical bugs or security defects are being considered for inclusion by the project maintenance team. Expect the project to be archived soon. Expect slow replies to issues.

意思就是项目组决定，现在不会给heketi开发新功能了，只会在现有基础上补缺补漏，并将在未来不久彻底停止维护。并且其还提到了:

It has been well over a year since we first entered maintenance mode. To anyone looking at creating a new install using Heketi: we highly encourage you to look at other appraoches to dynamic storage provisioning, especially if you're not already very familiar with Heketi/Gluster.

这意味着使用GlusterFS+Heketi作为CSI接口提供数据持久化已不再被建议，将来如果遇到问题，社区将无法获得官方支持，故弃用GlusterFS。

LocalEBS

LocalEBS是很多K8s初学者上路用的第一个的数据持久化方案，它可能适合测试或者跑跑自己的服务，但由于其功能有限，性能瓶颈较大，无法保证数据高可用且对存储卷声明支持较弱(仅支持ReadWriteOnce这一种方式)，所以弃用。

为什么使用Ceph?

高性能

高性能ですから！
我可是高性能的嘛
Ceph采用CRUSH算法，并行度和数据分布均衡度降维打击了一众传统的集中式存储元数据寻址方案。而且其理论上能支持上千个存储节点同时存在于一个集群之内，TB到PB级的数据存储。

高扩展性

Ceph是去中心化的，其实际性能随着节点增加而线性增长，并且扩展灵活，不会对现有集群造成过多破坏。

高可用

Ceph没有单点故障导致的整体服务崩溃，在一些常见的故障场景下，它能实现自愈和故障域隔离，同时数据保持强一致性。

高兼容性

Ceph支持三种存储接口: 块存储、文件存储、对象存储，并且其支持自定义接口，支持多种语言实现的驱动。

综上所述，我认为Ceph是目前最能满足星河存储需求的集群方案，但Ceph也有两种方式实现K8s集群的数据持久化，详见《用 Ceph 实现 K8s 集群数据持久化 #2》