更新！。 在評論中，一位讀者建議嘗試 （也許他自己正在研究這個問題）所以我添加了一個關於這個解決方案的部分。 我也寫過 ，因為這個過程與其他過程非常不同。
說實話我已經放棄放棄了 （最起碼到現在）。 我會用 。 為什麼？ 因為儲存！ 誰會想到我會對儲存進行更多的修改，而不是 Kubernetes 本身。 我用 因為它便宜而且性能好，從一開始我就一直使用它來部署集群 。 我沒有嘗試來自 Google/Amazon/Microsoft/DigitalOcean 等的託管 Kubernetes 服務，因為我想自己學習所有內容。 我也很節儉。
所以，是的，當我評估可能的 Kubernetes 堆疊時，我花了很多時間來決定選擇哪個儲存。 我更喜歡開源解決方案，不僅是因為價格，而且出於好奇我研究了一些付費選項，因為它們有一個有限制的免費版本。 當我比較不同的選項時，我記下了最近測試中的一些數字，這些數字可能對學習 Kubernetes 儲存的人感興趣。 雖然我個人現在已經告別了 Kubernetes。 我還想提一下 ，它可以直接配置 Hetzner Cloud 卷，但我還沒有嘗試過。 我研究了雲端軟體定義存儲，因為我需要複製以及在任何節點上快速安裝持久卷的能力，特別是在節點發生故障和其他類似情況的情況下。 有些解決方案提供時間點快照和異地備份，這很方便。
我測試了 6-7 個儲存解決方案：
正如我已經說過的 在測試了清單中的大部分選項後，我最初選擇了 OpenEBS。 OpenEBS 非常容易安裝和使用，但說實話，在使用真實資料負載進行測試後，我對其效能感到失望。 這是開源的，開發者自己 當我需要幫助時總是非常有幫助。 不幸的是，與其他選項相比，它的性能非常差，因此必須重新運行測試。 OpenEBS 目前有 3 個儲存引擎，但我發布的是 cStor 的基準測試結果。 我還沒有 Jiva 和 LocalPV 的數據。
簡而言之，Jiva 快一點，LocalPV 整體快，不比直接進行磁碟基準測試差。 LocalPV的問題是卷只能在準備它的節點上訪問，並且根本不存在複製。 我透過以下方式恢復備份時遇到一些問題 在新叢集上，因為節點名稱不同。 如果我們談論備份，cStor 有 ，可以對某個時間點的快照進行異地備份，比使用 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 到目前為止似乎非常有效。 安裝並不困難，但也不像其他選項那麼容易。 首先，我必須直接在主機上安裝 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 遇到的問題最少，但它的效能卻很糟糕。 遺憾的是我沒有保存更多結果，但我希望這些數字和我的評論會對您有所幫助。
來源： www.habr.com
