kubernetes - Kubernetes外部供应商与CSI

假设我有一台类似目标的iSCSI服务器，该服务器(就像目标一样)可以通过API设置iSCSI LUN。为了使该iSCSI服务器与K8的动态PV设置配合使用，经过一些Google搜索，我发现了两种可能的解决方案。

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

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

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

最佳答案

实际上，CSI是用于存储配置的标准化方法，根据我的经验，如今您可以通过多种选择来获得iSCSi(模拟)块存储，我建议使用:

rook.io:非常好，很不错的文档，涵盖了存储的不同方面(块，文件，对象以及用于不同的后端...)

gluster-block:它是用于存储gluster的插件，与heketi结合使用。参见文档k8s provisioning

顺便说一句，gluster是RedHat在Openshift 3上采用的CSI解决方案，它相当不错，感觉像Openshift 4在Ceph中很有用(很可能是菜鸟)

关于kubernetes - Kubernetes外部供应商与CSI，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/55841581/