代码之家  ›  专栏  ›  技术社区  ›  fengye87

库伯内特斯外部供应员vs CSI

  •  0
  • fengye87  · 技术社区  · 6 年前

    比如说,我有一台类似于targetd的iSCSI服务器,它(就像targetd一样)可以通过API配置iSCSI LUN。为了让这台iSCSI服务器与K8s动态PV资源调配配合使用,我在谷歌搜索后发现了两种可能的解决方案。

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

    但是,因为我已经知道K8s支持静态预配置的iSCSI LUN,所以我想知道是否可以只执行动态配置部分,将所有繁重的提升(装载和iscsiadm命令)留给K8s内置的iSCSI功能。后来我发现 iSCSI-targetd provisioner 对于K8s。它似乎比CSI插件简单得多,而且只花了150 LOC就为我的iSCSI服务器实现了provisioner。

    我有一个模糊的印象,K8s社区现在正在转向外部存储集成的CSI。这是否意味着我的后一种provisioner方式可能会被弃用,应该转向CSI插件?

    0 回复  |  直到 6 年前
        1
  •  1
  •   gonzalesraul    6 年前

    事实上,CSI是存储资源调配的标准化方法,您现在可以使用多种选项获得iSCSi(模拟)块存储,根据我的经验,我建议您使用:

    • rook.io :非常好的文档,涵盖了存储的不同方面(块、文件、对象和不同的后端…)
    • gluster-block :这是一个用于gluster存储的插件,与heketi结合使用。见文件 k8s provisioning

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