Kubernetes external provisioner vs CSI

4/25/2019

Say like I have a targetd-alike iSCSI server, which (just like targetd) can provision iSCSI LUNs via APIs. To make this iSCSI server work with K8s dynamic PV provisioning, I've found two possible solutions after some Googlings.

The first solution is CSI. Basically, I need to implement a CSI plugin that translate volume creation requests to LUN creation API calls, and also translate stash/mount requests to iscsiadm commands.

However, as I already knew that K8s supports statically pre-provisioned iSCSI LUN out-of-box, I wondered if I could just do the dynamic provision part and leave all the heavy-liftings (mount and iscsiadm commands) to K8s built-in iSCSI functionality. So later, I've found iSCSI-targetd provisioner for K8s. It seems much simpler than a CSI plugin, and it only took 150 LOC to implement my provisioner for my iSCSI server.

I have a vague impression that K8s community is now moving towards CSI for external storage integrations. Does this mean that my latter provisioner way could be deprecated and should move to a CSI plugin?

-- fengye87
kubernetes

1 Answer

4/25/2019

In fact CSI is the standardized way to storage provisioning, you can get iSCSi (emulated) block storage with several options nowadays, based on my experience, I would recommend to use:

  • rook.io: Really great, good docs and coverage different aspects of storage (block,file,object and for different backends ...)
  • gluster-block: it is a plug-in for gluster storage, this is used combined with heketi. See docs k8s provisioning

By the way, gluster is the solution for CSI adopted by RedHat on Openshift 3, and it is pretty decent, feels like for Openshift 4 will be something with Ceph (mostly likely rook)

-- gonzalesraul
Source: StackOverflow