Kubernetes 中的存储：OpenEBS、Rook (Ceph)、Rancher Longhorn、StorageOS、Robin、Portworx、Linstor

更新！。 在评论中，一位读者建议尝试 林斯托 （也许他自己正在研究这个问题）所以我添加了一个关于这个解决方案的部分。 我也写过 发布关于如何安装它的帖子，因为这个过程与其他过程非常不同。

说实话我已经放弃放弃了 Kubernetes （最起码到现在）。 我会用 Heroku的。 为什么？ 因为存储！ 谁会想到我会对存储进行更多的修改，而不是 Kubernetes 本身。 我用 赫兹纳云因为它便宜而且性能好，从一开始我就一直使用它来部署集群 农场工人。 我没有尝试来自 Google/Amazon/Microsoft/DigitalOcean 等的托管 Kubernetes 服务，因为我想自己学习所有内容。 我也很节俭。

所以，是的，当我评估可能的 Kubernetes 堆栈时，我花了很多时间来决定选择哪个存储。 我更喜欢开源解决方案，不仅是因为价格，而且出于好奇我研究了一些付费选项，因为它们有有限制的免费版本。 当我比较不同的选项时，我记下了最近测试中的一些数字，这些数字可能对那些学习 Kubernetes 存储的人感兴趣。 虽然我个人现在已经告别了 Kubernetes。 我还想提一下 CSI驱动程序，它可以直接配置 Hetzner Cloud 卷，但我还没有尝试过。 我研究了云软件定义存储，因为我需要复制以及在任何节点上快速安装持久卷的能力，特别是在节点发生故障和其他类似情况的情况下。 有些解决方案提供时间点快照和异地备份，这很方便。

我测试了 6-7 个存储解决方案：

开放EBS

正如我已经说过的 在上一篇文章中在测试了列表中的大部分选项后，我最初选择了 OpenEBS。 OpenEBS 非常易于安装和使用，但说实话，在使用真实数据负载进行测试后，我对其性能感到失望。 这是开源的，开发者自己 松弛通道 当我需要帮助时总是非常有帮助。 不幸的是，与其他选项相比，它的性能非常差，因此必须重新运行测试。 OpenEBS 目前有 3 个存储引擎，但我发布的是 cStor 的基准测试结果。 我还没有 Jiva 和 LocalPV 的数据。

简而言之，Jiva 快一点，LocalPV 总体快，不比直接进行磁盘基准测试差。 LocalPV的问题是卷只能在准备它的节点上访问，并且根本不存在复制。 我通过以下方式恢复备份时遇到一些问题 帆船 在新集群上，因为节点名称不同。 如果我们谈论备份，cStor 有 Velero 插件，可以对某个时间点的快照进行异地备份，比使用 Velero-Restic 进行文件级备份更加方便。 我写 几个脚本，以便更轻松地使用此插件管理备份和恢复。 总的来说，我真的很喜欢 OpenEBS，但是它的性能......

车

Rook 也是开源的，与列表中的其他选项不同，它是一个存储编排器，可以使用不同的后端执行复杂的存储管理任务，例如 头孢, 边缘文件系统 和其他，这大大简化了工作。 几个月前我尝试 EfgeFS 时遇到了问题，所以我主要使用 Ceph 进行测试。 Ceph不仅提供块存储，还提供兼容S3/Swift和分布式文件系统的对象存储。 我喜欢 Ceph 的一点是它能够将卷数据分布到多个磁盘上，这样卷就可以使用比单个磁盘所能容纳的更多的磁盘空间。 很舒服。 另一个很酷的功能是，当您将磁盘添加到集群时，它会自动在所有磁盘之间重新分配数据。

Ceph有快照，但据我所知，不能直接在Rook/Kubernetes中使用。 确实，我没有深入探讨这一点。 但没有异地备份，所以你必须使用 Velero/Restic 的东西，但只有文件级备份，没有时间点快照。 我真正喜欢 Rook 的是它与 Ceph 的使用是多么容易——它隐藏了几乎所有复杂的东西，并提供了直接与 Ceph 对话以进行故障排除的工具。 不幸的是，在对 Ceph 卷进行压力测试期间，我一直遇到以下问题： 这个问题，这会导致 Ceph 变得不稳定。 目前尚不清楚这是 Ceph 本身的 bug，还是 Rook 管理 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 的效果非常显著。它的配置并不难，但不如其他方案那么简单。首先，我必须在 Kubernetes 之外，直接在主机上安装 Linstor（内核模块和工具/服务），并配置 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 遇到的问题最少，但它的性能却很糟糕。 遗憾的是我没有保存更多结果，但我希望这些数字和我的评论会对您有所帮助。

来源： habr.com