Kubernetes 外部供應商與 CSI

Question

假設我有一個類似目標的 iSCSI 服務器，它（就像目標）可以通過 API 配置 iSCSI LUN。 為了使這個 iSCSI 服務器與 K8s 動態 PV 配置一起工作，我在谷歌搜索后找到了兩種可能的解決方案。

第一個解決方案是CSI 。 基本上，我需要實現一個 CSI 插件，將卷創建請求轉換為 LUN 創建 API 調用，並將存儲/掛載請求轉換為 iscsiadm 命令。

然而，因為我已經知道 K8s 支持靜態預配置 iSCSI LUN 開箱即用，我想知道我是否可以只做動態配置部分並將所有繁重的工作（mount 和 iscsiadm 命令）留給 K8s 內置iSCSI 功能。 所以后來，我發現了針對 K8s 的iSCSI 目標配置器。 它似乎比 CSI 插件簡單得多，而且只需要 150 LOC 就可以為我的 iSCSI 服務器實現我的配置器。

我有一個模糊的印象，K8s 社區現在正在轉向 CSI 以進行外部存儲集成。 這是否意味着我的后一種供應商方式可能會被棄用而應該轉移到 CSI 插件？

Answer 1

事實上，CSI 是存儲配置的標准化方式，現在您可以通過多種選項獲得 iSCSi（模擬）塊存儲，根據我的經驗，我建議使用：

• rook.io ：真的很棒，很好的文檔，涵蓋了存儲的不同方面（塊、文件、對象和不同的后端......）
• gluster-block ：gluster 存儲插件，與 heketi 結合使用。 請參閱文檔k8s 配置

順便說一句，gluster 是 RedHat 在 Openshift 3 上采用的 CSI 解決方案，而且相當不錯，感覺 Openshift 4 將與 Ceph 結合（很可能是車）