为什么Ceph比Glusterfs更适合接入k8s

如果团队不是实在搞不定ceph的话，个人建议，现阶段不建议k8s的后端存储使用glusterfs. 因为问题比较多.

首先说明一下,glusterfs这种无中心架构，节点之间采用全互联模式的，也就意味着通信带宽消耗要求会比master/slave这种高很多.

另外glusterfs更加适合做冷数据存储集群，也就是一些重要数据压缩打包以后放在那里.我们这边目前使用glusterfs集群发现，很多上层应用的支持非常不好，例如nexus官方已经明确说明不支持该存储了.还有很多虽然没有明确说明，但是其实对glusterfs这种架构的支持度是不太友好的.

还有很重要一点，glusterfs的生态远远没有ceph的好，虽然现在glusterfs官方版本也出到9.x了，但是像heketi这样的工具，用来k8s管理glusterfs集群增删改glusterfs的volume的，这玩意目前已经停止维护了.还有glusterfs-exporter,这个的监控工具，官方也停止维护了.这段时间使用就发现了一些问题，例如exporter这种居然不是每个节点收集的信息一样的，会查看glusterfs所有节点的uuid,然后找到默认最大的那个才是收集最全面的信息的，其他节点是会缺少一些信息.这个内容官方就没有很明确提出来，只是建议让你在所有节点都部署exporter,但是那样对集群来说其实负担比较大的，因为一个volume status命令是需要所有节点来通信的.如果两三百个volume,然后每个volume都来一下，想想这个通信量就很可观了.

接着，对于glusterfs来说，这玩意对linux文件系统的关联度实在很大，里面有超级多的参数，云里雾里的，甚至官方也不一定能完全给出可靠的解释，例如open-behind,这个参数官方说是对于打开文件句柄那块有优化的，但是我们使用的时候发现了很多bug，在7.7及之前的版本，会出现文件句柄异常这样的问题，导致挂载中断，这在k8s里面会导致pod不断重启的.但是到底这玩意是怎么生效的，作用如何，查过很多资料，目前还不明确，当然可能也是个人理解水平问题.

当然也想说一点，现在去各大app上买书的话，glusterfs目前没有一本书！这是重点，意味着你想深入理解这个工具，只能靠网上的资料或者源码了，而网上的内容，大部分还是3.x版本的，现在已经9.x了.同时国内懂这个的真的很少很少.所以你想找懂优化的人，那就更少了...还有就是虽然官方在github上给出了doc文档，但是我看了其中的一部分，很多内容讲的太生涩难懂了，有些内容如果你不是对fuse那些非常熟悉的话，估计都不知道那玩意在干嘛.

所以真的，大部分情况下，ceph都是目前k8s集群比较好的选择，至少会比glusterfs这边好很多，当然未来不敢说，至少目前现阶段，glusterfs的生态还是有很多很多问题的.

标签：volume,glusterfs,Ceph,Glusterfs,官方,集群,k8s,节点
来源： https://blog.51cto.com/dellinger/2926544