更新!。 在评论中,一位读者建议尝试
说实话我已经放弃放弃了
所以,是的,当我评估可能的 Kubernetes 堆栈时,我花了很多时间来决定选择哪个存储。 我更喜欢开源解决方案,不仅是因为价格,而且出于好奇我研究了一些付费选项,因为它们有有限制的免费版本。 当我比较不同的选项时,我记下了最近测试中的一些数字,这些数字可能对那些学习 Kubernetes 存储的人感兴趣。 虽然我个人现在已经告别了 Kubernetes。 我还想提一下
我测试了 6-7 个存储解决方案:
开放EBS
正如我已经说过的
简而言之,Jiva 快一点,LocalPV 总体快,不比直接进行磁盘基准测试差。 LocalPV的问题是卷只能在准备它的节点上访问,并且根本不存在复制。 我通过以下方式恢复备份时遇到一些问题
车
Rook 也是开源的,与列表中的其他选项不同,它是一个存储编排器,可以使用不同的后端执行复杂的存储管理任务,例如
Ceph有快照,但据我所知,不能直接在Rook/Kubernetes中使用。 确实,我没有深入探讨这一点。 但没有异地备份,所以你必须使用 Velero/Restic 的东西,但只有文件级备份,没有时间点快照。 我真正喜欢 Rook 的是它与 Ceph 的使用是多么容易——它隐藏了几乎所有复杂的东西,并提供了直接与 Ceph 对话以进行故障排除的工具。 不幸的是,在对 Ceph 卷进行压力测试期间,我一直遇到以下问题:
牧场主长角牛
我真的很喜欢长角。 在我看来,这是一个有前途的解决方案。 确实,开发人员自己(Rancher Labs)承认它还不适合工作环境,这表明了这一点。 它是开源的并且具有不错的性能(尽管他们还没有对其进行优化),但是卷需要很长时间才能连接到 Pod,在最坏的情况下需要 15-16 分钟,尤其是在恢复大型备份或升级工作量。 它有快照和这些快照的异地备份,但它们仅适用于卷,因此您仍然需要像 Velero 这样的东西来备份其他资源。 备份和恢复非常可靠,但速度非常慢。 说实话,速度太慢了。 在 Longhorn 中处理中等数据量时,CPU 使用率和系统负载通常会出现峰值。 有一个方便的仪表板来管理 Longhorn。 我已经说过我喜欢 Longhorn,但它还需要一些改进。
存储操作系统
StorageOS是榜单上第一个付费产品。 它有一个开发人员版本,管理存储大小有限为 500GB,但我认为节点数量没有限制。 销售部门告诉我,如果我没记错的话,125 TB 的起价为每月 1 美元。 有一个基本的仪表板和一个方便的 CLI,但性能出现了一些奇怪的情况:在某些基准测试中它相当不错,但在容量压力测试中我根本不喜欢它的速度。 总的来说,我不知道该说什么。 所以我其实不太了解。 这里没有异地备份,您还必须使用 Velero 和 Restic 来备份卷。 这很奇怪,因为产品是付费的。 而且开发人员并不急于在 Slack 上进行交流。
知更鸟
我是在 Reddit 上从他们的技术总监那里了解到 Robin 的。 我以前从未听说过他。 也许是因为我正在寻找免费的解决方案,但罗宾是付费的。 他们有一个相当慷慨的免费版本,具有 10TB 存储空间和三个节点。 总体而言,该产品相当不错,并且具有不错的功能。 有一个很棒的 CLI,但最酷的是您可以快照和备份整个应用程序(在资源选择器中这称为 Helm 版本或“flex 应用程序”),包括卷和其他资源,因此您可以在没有 Velero 的情况下进行操作。 如果不是一个小细节,一切都会很棒:如果您在新集群上恢复(或“导入”,Robin 中称之为“导入”)应用程序 - 例如,在从灾难中恢复时 - 恢复,当然可以,但继续备份应用程序是被禁止的。 正如开发人员所证实的那样,在此版本中这是不可能的。 温和地说,这很奇怪,特别是考虑到其他优点(例如,令人难以置信的快速备份和恢复)。 开发人员承诺在下一个版本中修复所有问题。 性能总体不错,但我注意到一个奇怪的现象:如果我直接在连接到主机的卷上运行基准测试,则读取速度比在 pod 内运行相同卷要快得多。 所有其他结果都是相同的,但理论上应该没有差异。 尽管他们正在努力,但我对恢复和备份的问题感到不安 - 我以为我终于找到了合适的解决方案,当我需要更多空间或更多服务器时,我什至愿意为此付费。
波特沃克斯
我在这里没什么可说的。 这是一款付费产品,同样很酷,但也很昂贵。 性能简直令人惊叹。 这是迄今为止最好的指标。 Slack 告诉我,每个节点的起价为每月 205 美元,如 Google 的 GKE Marketplace 中列出的那样。 不知道直接买会不会便宜一些。 无论如何,我买不起,所以我非常非常失望,除非您满足于静态配置,否则开发人员许可证(最多 1 TB 和 3 个节点)对于 Kubernetes 几乎毫无用处。 我希望批量许可证会在试用期结束时自动降级为开发人员,但这并没有发生。 开发者许可证只能直接与Docker一起使用,并且在Kubernetes中的配置非常繁琐和有限。 当然,我更喜欢开源,但如果我有钱,我肯定会选择Portworx。 到目前为止,它的性能根本无法与其他选项相比。
林斯托
当一位读者建议尝试 Linstor 时,我在这篇文章发布后添加了这一部分。 我尝试过,我喜欢它! 但我们仍然需要更深入地挖掘。 现在我可以说性能还不错(我在下面添加了基准测试结果)。 本质上,我直接获得了与磁盘相同的性能,没有任何开销。 (不要问为什么 Portworx 的数据比直接的驱动器基准更好。我不知道。我猜是魔法。)所以 Linstor 到目前为止似乎非常有效。 安装并不困难,但也不像其他选项那么容易。 首先,我必须直接在主机上安装 Linstor(内核模块和工具/服务)并配置 LVM 以实现 Kubernetes 外部的精简配置和快照支持,然后创建使用 Kubernetes 存储所需的资源。 我不喜欢它不能在 CentOS 上运行,我不得不使用 Ubuntu。 当然,这并不可怕,但有点烦人,因为文档(顺便说一句,非常棒)提到了几个在指定的 Epel 存储库中找不到的包。 Linstor 有快照,但没有异地备份,所以这里我不得不再次使用 Velero 和 Restic 来备份卷。 我更喜欢快照而不是文件级备份,但如果解决方案高性能且可靠,这是可以容忍的。 Linstor 是开源的,但有付费支持。 如果我理解正确的话,即使您没有支持合同,它也可以不受限制地使用,但这需要澄清。 我不知道 Linstor 在 Kubernetes 上的测试情况如何,但存储层本身位于 Kubernetes 之外,而且显然昨天还没有出现该解决方案,因此它可能已经在实际条件下进行了测试。 这里有没有一个解决方案可以让我改变主意并回到 Kubernetes? 我不知道。 我们仍然需要更深入地挖掘和研究复制。 让我们来看看。 但第一印象很好。 我肯定更愿意使用自己的 Kubernetes 集群而不是 Heroku,以获得更多自由并学习新事物。 由于 Linstor 不像其他人那么容易安装,我很快就会写一篇关于它的文章。
基准
不幸的是,我没有对比较做很多笔记,因为我认为我不会写它。 我只有基本 fio 基准测试的结果,并且只有单节点集群的结果,因此我还没有复制配置的数据。 但从这些结果中,您可以粗略地了解每个选项的预期效果,因为我在相同的云服务器、4 核、16 GB RAM 以及用于测试卷的额外 100 GB 磁盘上对它们进行了比较。 我为每个解决方案运行了三次基准测试并计算了平均结果,此外我还为每个产品重置了服务器设置。 这完全不科学,只是为了给你一个大概的想法。 在其他测试中,我从卷中复制了 38 GB 的照片和视频来测试读写,但是,可惜的是,我没有保存这些数字。 简而言之:Portworkx 速度更快。
对于体积基准,我使用了这个清单:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4
我首先创建了一个具有适当存储类的卷,然后在幕后使用 fio 运行该作业。 我花了 1 GB 来估计性能,并没有等待太久。 结果如下:
我用绿色突出显示了每个指标的最佳值,用红色突出显示了最差值。
结论
正如您所看到的,在大多数情况下,Portworx 的表现都比其他产品更好。 但对我来说它很贵。 我不知道 Robin 的价格是多少,但他们有一个很棒的免费版本,所以如果你想要付费产品,你可以尝试一下(希望他们很快就能解决恢复和备份问题)。 在这三个免费软件中,我使用 OpenEBS 遇到的问题最少,但它的性能却很糟糕。 遗憾的是我没有保存更多结果,但我希望这些数字和我的评论会对您有所帮助。
来源: habr.com