时至今日,企业客户运行容器的,编排工具大多数选择K8S。
因此,我们先到社区里看看,目前K8S支持的持久存储,其实也就是PV支持的存储类型。
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
其中,AWS、GCE、Azure都是公有云的存储方式,本文不进行分析。
● vSphere的存储指的是用vSAN的Datastore
● Quobyte是2013年成立的一公司,
● 家Quobyte也是一家SDS的公司,K8S支持Quobyte的文件系统。
● 根据Linux基金会公布的数据,目前:能够支持K8S的开源、分布式SDS项目,Ceph和GlusterFS排名是很靠前的。(详细参照:https://www.linux.com/news/open-cloud-report/2016/guide-open-cloud-software-defined-storage-opens)。
我们看一下github上ceph项目的情况:
再看一下GlusterFS项目的情况:
从社区活跃度看,目前ceph要高很多。那么,是不是容器存储就应该选Ceph?如果客户选择Docker+K8S或者Openshift构建私有容器云,存储选择哪种方式比较好?
下面,针对Openshift的应用场景,我们对GlusterFS、Ceph RBD以及NFS的优缺点进行分析:
对比项 | Ceph RBD | Glusterfs | SAN+NFS |
---|---|---|---|
Openshift平台容器数据持久化的支持 | 支持Pod级的动态创建,不支持ReadWriteMany;当Kubernetes运行在OpenStack上时,它是最好的存储 | 支持动态分配;支持ReadWriteOnce和ReadWriteMany;Container Native Storage | 静态支持,手动和静态预先支持,空间分配低效,容器级别安全性有待提升;普遍使用的,易于设置PoC,易于理解;支持ReadWriteOnce和ReadWriteMany |
高可用 | Ceph系统提供了对象、块、和文件存储功能,使用CRUSH算法维护存储对象与存储服务器的对应关系,无Master设计。对象复制,集群扩容,数据迁移,故障检测和处理等复杂功能由Ceph OSD(Object Storage Device)提供,避免了单点失败 | Glusterfs开源的分布式文件系统,没有元数据服务器层,存储使用弹性哈希算法来查找存储池中的数据(通过文件名来计算哈希值),从而消除了单点故障和导致 I/O 瓶颈的常见根源和故障多发情况 | 依赖于存储硬件和NFS |
数据保护 | Ceph OSD 守护进程自动在其它 Ceph 节点上创建对象副本来确保数据安全和高可用性,存储池快照 | 数据分布与跨节点的多个bricks,支持在线卷快照(Volume Snapshot),可恢复镜像时间点数据,同时支持跨区域(WLAN)的异步主备份卷复制 | 依赖于存储硬件RAID、快照、和复制 |
扩展性能 | 可以动态添加节点和硬盘 | 可以动态增加或缩减数据存储池和节点 | 可以动态增加或缩减数据存储池,依赖于存储硬件 |
caching/分层存储能力 | 支持,比如:ssd盘组成的缓冲层(IO性能要求高的应用)而相对低速、便宜的设备,作为经济存储层(IO性能要求低) | 支持,比如:ssd盘组成的缓冲层(IO性能要求高的应用)而相对低速、便宜的设备,作为经济存储层(IO性能要求低) | 支持,依赖于存储硬件 |
安装和管理 | 安装简单,维护较复杂 | 安装、维护简单 | 安装、维护简单 |
故障恢复 | 但节点失效时,自动迁移数据,重新复制副本 | 当节点、硬件、磁盘、网络故障时,系统能自动处理,无须管理员介入。 | 依赖于存储硬件 |
成本 | 硬件成本低 | 硬件成本低 | 硬件成本高 |
综合以上参数,Openshift平台优先Gluster,Openstack优先Ceph RBD,当不考虑成本及易用性的角度可以用NFS。
同样,如果客户使用Openshift,SDN如何选择?请看下表。
对比项 | Openshift SDN | Calico | Contive |
---|---|---|---|
实现机制 | 基于OVS bridge vxlan | 基于BGP的三层交换 | 基于OVS的2层交换,也支持BGP三层交换 |
网络模型 | 支持Kubernetes CNI | CNI,CNM | CNI,CNM |
多租户 | 支持 | 不支持 | 支持 |
包转发性能 | 性能损耗较低 | 性能损耗低 | vxlan性能损失较高 |
Vxlan支持 | 支持 | 不支持 | 支持 |
QOS支持 | There is experimental support | 不支持 | 支持 |
访问控制策略 | 基于Openflow,三方插件 | 基于iptables,calico network policy | Openflow |
软件成熟度 | 高 | 中等 | 低 |
易用性和可维护性 | 好 | 中等,当规模较大时候增加维护难度 | 低 |
网络硬件依赖 | 低 | BGP协议,可能对硬件有一定侵入性 | 依赖厂家特定交换机 |
可扩展性 | 强 | 强 | 强 |
二次开发 | 中等 | 中等 | 较高 |
综合以上参数,Openshift平台优先选择Openshift SDN。
本文转自微信公众号:大卫分享
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论0 条评论