容器的存储和网络开源方案该咋选？
容器存储的选择
时至今日，企业客户运行容器的，编排工具大多数选择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作者其他文章
评论 1 · 赞 9
评论 0 · 赞 1
评论 0 · 赞 8
评论 1 · 赞 7
评论 0 · 赞 5
添加新评论0 条评论