Kubernetes external provisioner vs CSI

Question

假设我有一个类似于targetd的iSCSI服务器，它(就像targetd一样)可以通过API调配iSCSI LUN。为了使这个iSCSI服务器能够与K8s dynamic PV provisioning一起工作，我在谷歌搜索之后找到了两种可能的解决方案。

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

但是，因为我已经知道K8s支持开箱即用的静态预资源调配iSCSI LUN，所以我想知道是否可以只做动态资源调配部分，而将所有繁重的工作(装载和iscsiadm命令)留给K8s内置的iSCSI功能。所以后来，我找到了用于K8s的iSCSI-targetd provisioner。它看起来比CSI插件简单得多，而且只需要150LOC就可以为我的iSCSI服务器实现我的provisioner。

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

Answer 1

实际上，CSI是存储资源调配的标准化方法，您现在可以通过几个选项获得iSCSi (模拟)数据块存储，根据我的经验，我建议使用：

请参阅文档k8s provisioning

顺便说一句，gluster是RedHat在Openshift 3上采用的CSI解决方案，它相当不错，感觉Openshift 4将与Ceph一起使用(很可能是rook)