Kubernetes外部供应商与CSI

Question

比如我有一个类似目标的iSCSI服务器，它（就像目标一样）可以通过API配置iSCSI LUN。为了使这个iSCSI服务器与K8s动态PV配置一起工作，我在一些谷歌搜索之后找到了两种可能的解决方案。

第一个解决方案是CSI。基本上，我需要实现一个CSI插件，将卷创建请求转换为LUN创建API调用，并将存储/挂载请求转换为iscsiadm命令。

但是，正如我已经知道K8支持静态预配置的iSCSI LUN开箱即用，我想知道我是否可以只执行动态配置部分并将所有繁重的工作（mount和iscsiadm命令）留给K8内置iSCSI功能。所以后来，我为K8s找到了iSCSI-targetd provisioner。它似乎比CSI插件简单得多，而且我的iSCSI服务器只需要150个LOC来实现我的配置器。

我有一种模糊的印象，即K8社区现在正朝着CSI进行外部存储集成。这是否意味着我的后一种供应方式可能会被弃用并且应该转移到CSI插件？

Answer 1

事实上，CSI是存储配置的标准化方式，现在您可以通过多种选项获得iSCSi（仿真）块存储，根据我的经验，我建议使用：

• rook.io：真的很棒，很好的文档和覆盖存储的不同方面（块，文件，对象和不同的后端......）
• gluster-block：它是gluster存储的插件，与heketi结合使用。请参阅docs k8s provisioning

顺便说一句，gluster是RedHat在Openshift 3上采用的CSI的解决方案，它相当不错，感觉就像Openshift 4将是Ceph的东西（很可能是车）