🥇Kubernetes 中的儲存：OpenEBS vs Rook（Ceph） vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs 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 遇到的問題最少，但它的效能卻很糟糕。遺憾的是我沒有保存更多結果，但我希望這些數字和我的評論會對您有所幫助。

來源： www.habr.com