更新！ 。 在评论中，一位读者建议尝试使用Linstor （也许他自己进行这项工作），因此我添加了有关此解决方案的部分。 我还写了一篇有关如何安装它的文章 ，因为该过程与其余过程有很大不同。
老实说，我放弃并放弃了Kubernetes （至少现在是这样）。 我将使用Heroku 。 怎么了 因为有存储！ 谁会想到我会比Kubernetes本身更喜欢存储。 我之所以使用Hetzner Cloud是因为它便宜且性能良好，并且从一开始我就使用Rancher部署了集群。 我没有尝试过Google / Amazon / Microsoft / DigitalOcean等提供的Kubernetes托管服务，因为我想自己学习一切。 而且我很经济。
所以-是的，当我考虑使用Kubernetes上可能的堆栈时，我花了很多时间试图决定选择哪个存储。 我更喜欢开源解决方案，不仅因为价格高，而且出于好奇心，我研究了一些付费选项，因为它们有限制的免费版本。 当我比较不同的选择时，我写下了最新测试中的一些数字，而那些研究Kubernetes中存储的人可能会感兴趣。 到目前为止，尽管我个人已经告别了Kubernetes。 我还想提到CSI驱动程序 ，您可以在其中直接准备Hetzner Cloud卷，但是我还没有尝试过。 我研究了基于云的软件定义的存储，因为我需要复制以及能够在任何节点上快速挂载持久卷的能力，尤其是在出现节点故障和其他类似情况的情况下。 一些解决方案可在某个时间点提供快照并提供异地备份，这很方便。
我测试了6-7个存储解决方案：
正如我在上一篇文章中所说， 在测试了列表中的大多数选项之后 ，我最初选择了OpenEBS。 OpenEBS非常易于安装和使用，但是说实话，在负载下对真实数据进行测试后，其性能令我失望。 这是一个开放源码，当我需要帮助时，他们在Slack频道上的开发人员总是提供了很多帮助。 不幸的是，与其他选项相比，它的性能非常低，因此我不得不再次运行测试。 OpenEBS现在具有3个存储引擎，但是我要发布cStor的基准测试结果。 到目前为止，我还没有Jiva和LocalPV的编号。
简而言之，Jiva的速度要快一些，而LocalPV的速度通常要快一些，并不比直接驱动器的基准还要差。 LocalPV的问题在于，只能在准备好卷的节点上获得对卷的访问，并且绝对没有复制。 我在通过新集群上的Velero恢复备份时遇到了一些问题，因为节点名称不同。 如果我们谈论备份，则cStor有一个Velero插件 ，您可以使用该插件一次对快照进行非现场备份，这比使用Velero-Restic进行文件级备份更方便。 我编写了一些脚本，以使使用此插件管理备份和还原变得更容易。 总的来说，我真的很喜欢OpenEBS，但是它的性能...
Rook也具有开源代码，它与列表中的其他选项不同，它是一个存储编排器，它执行复杂的任务来管理具有不同后端的存储，例如Ceph ， EdgeFS等，这大大简化了工作。 几个月前我尝试使用EfgeFS时遇到问题，所以我主要使用Ceph进行了测试。 Ceph不仅提供块存储，还提供与S3 / Swift和分布式文件系统兼容的对象存储。 我对Ceph的喜欢是能够在多个磁盘上分配卷数据，以便该卷可以使用比单个磁盘可容纳的更多的磁盘空间。 这很方便。 另一个很酷的功能是，当您将磁盘添加到群集时，它将自动在所有磁盘之间重新分配数据。
Ceph中有快照，但是据我所知，它们不能直接在Rook / Kubernetes中使用。 没错，我没有参加。 但是，在站点外没有备份，因此您必须在Velero / Restic上使用某些工具，但是只有文件级别的备份，而当时没有快照。 但是在Rook中，我真的很喜欢Ceph的简单工作-它隐藏了几乎所有复杂的事物，并提供了与Ceph直接通信以进行故障排除的工具。 不幸的是，在Ceph容量的压力测试中，由于Ceph变得不稳定，所以我一直都遇到这个问题 。 目前尚不清楚这是Ceph本身的错误还是Rook如何控制Ceph的问题。 我想到了内存设置，它变得更好了，但是直到最后才解决了问题。 如下面的基准测试所示，Ceph的性能很好。 他也有一个很好的仪表板。
我真的很喜欢长角牛。 我认为，这是一个很有前途的解决方案。 的确，开发人员本身（Rancher Labs）承认它不适合工作环境，这一点可以看出。 它具有开放源代码和良好的性能（尽管尚未对其进行优化），但是卷需要很长时间才能连接到炉膛，在最坏的情况下，它需要15-16分钟，尤其是在还原大型备份或升级工作负载之后。 他具有快照和这些快照的异地备份，但它们仅适用于卷，因此您仍然需要Velero之类的东西来备份其他资源。 备份和恢复非常可靠，但是速度很慢。 严重的是，速度太慢了。 在Longhorn中使用平均数据时，CPU利用率和系统负载通常会增加。 有一个方便的仪表板来控制Longhorn。 我已经说过我喜欢Longhorn，但需要继续努力。
StorageOS是清单上第一款付费产品。 它具有供开发人员使用的版本，其受管存储空间有限，为500 GB，但我认为节点数量不受限制。 销售部门告诉我，如果我没有记错的话，1 TB的费用每月为125美元。 有一个基本的仪表板和一个方便的CLI，但是性能却发生了一些奇怪的事情：在某些基准测试中，它相当不错，但是在卷的压力测试中我根本不喜欢速度。 总的来说，我不知道该说些什么。 因此，我并不特别了解。 没有场外备份，您还必须将Velero与Restic一起使用以备份卷。 很奇怪，因为产品是付费的。 而且开发人员并不渴望在Slack中进行交流。
我从他们的技术总监那里了解了Robin on Reddit。 我以前从未听说过他。 也许是因为我在寻找免费的解决方案，而罗宾付了钱。 他们有一个非常慷慨的免费版本，具有10 TB的存储空间和三个节点。 总的来说，该产品相当不错并且具有不错的功能。 那里有一个很棒的CLI，但是很酷的事情是，您可以快照和备份整个应用程序（在资源选择器中称为Helm版本或“ flex应用程序”），包括卷和其他资源，因此无需Velero就可以做到。 如果不是一个小细节，一切都会很棒：如果在新集群上还原（或“导入”，如Robin所说的）应用程序（例如，在意外发生后进行恢复的情况下），恢复当然可以，但是继续备份应用程序不允许。 在此版本中，这根本不可能，并且开发人员已确认。 坦率地说，这很奇怪，尤其是在考虑其他优点（例如，令人难以置信的快速备份和恢复）时。 开发人员承诺会为下一版本修复所有问题。 通常，性能不错，但是我注意到一个奇怪的事情：如果直接在连接到主机的卷上运行基准测试，则读取速度要比同一个卷中的读取速度要高得多，但是从内部读取速度要高得多。 所有其他结果都是相同的，但理论上应该没有区别。 尽管他们正在为此工作，但是由于恢复和备份方面的问题，我感到很沮丧-在我看来，我终于找到了一个合适的解决方案，当我需要更多空间或更多服务器时，我甚至愿意为此付出代价。
我真的没有话要说了。 这是一种付费产品，既酷又昂贵。 业绩是奇迹。 到目前为止，这是最好的指标。 Slack告诉我，起价为每个节点每月205美元，如Google GKE Marketplace所示。 我不知道如果直接购买会便宜吗。 无论如何，我都买不起，所以我非常非常失望Kubernetes的开发人员许可证（最多1 TB和3个节点）几乎没有用，除非您对静态准备感到满意。 我希望批量许可在试用期结束时会自动降至开发人员的水平，但事实并非如此。 开发人员许可证只能直接与Docker一起使用，并且Kubernetes中的配置非常繁琐且受限制。 当然，我更喜欢开源，但如果有钱，我肯定会选择Portworx。 到目前为止，它的性能无法与其他选项相比。
帖子发布后，当一位读者建议尝试使用Linstor时，我添加了本节。 我尝试了，我喜欢它！ 但是您仍然必须挖掘。 现在我可以说性能还不错（我在下面添加了基准测试结果）。 实际上，我直接获得了与驱动器相同的性能，而且绝对没有开销。 （不要问为什么Portworx的数字直接比驱动器的基准更好。我不知道。魔术，也许是。）所以Linstor似乎仍然非常有效。 安装它没有那么困难，但没有其他选项那么容易。 首先，我必须直接在主机上安装Linstor（内核模块和工具/服务），并为Kubernetes外部的精简配置和支持快照配置LVM，然后从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的所有问题最少，但它的性能并不出色。 很遗憾，我没有保存更多结果，但是希望给出的数字和我的评论对您有所帮助。