Question about CSI driver for NFS like storage backend vendored by cloud provider

246 views
Skip to first unread message

panche...@gmail.com

unread,
Jan 28, 2019, 5:45:19 PM1/28/19
to kubernetes-sig-storage
Hi sig-storage,

I am working on a new CSI driver for AWS EFS which is NFS like filesystem vendored by AWS. I proposed it being transferred as a sig-aws kubernetes subproject at sig aws meeting.

During sig meeting, since different cloud providers have similar NFS backed storage services (like gcp file store, aws efs, nfs csi driver), question arises around should build upon the common NFS CSI driver or should each cloud provider build and maintain their own CSI driver for NFS like storage backend.

After a bit research, I found google already has a gcp file store csi driver. And for different NFS like storage backed, even if the NFS mount part is every similar on the node service, the controller service is still tightly coupled with different cloud provider's service API which make it hard to generalize. Also different cloud provide might have different features about storage encryption option like AWS EFS encryption in transit. So I feel it make sense to have a separate CSI driver for AWS EFS.

Would like to see how sig-storage thinks of this problem and any concerns of creating another CSI driver just for AWS EFS.

See here for sig-aws meeting notes at Jan.11th

Thanks,
Cheng

Saad Ali

unread,
Jan 28, 2019, 6:14:31 PM1/28/19
to panche...@gmail.com, kubernetes-sig-storage
Great question Cheng.

In general, for common storage protocols (iSCSI, NFS, and FibreChannel) the Storage SIG is advocating building "standard libraries" that can be imported by CSI driver authors to build custom CSI driver (to avoid duplicating coding everywhere).

There are 2 such libraries that already exist thanks to folks in the Storage SIG:
  1. https://github.com/kubernetes-csi/csi-lib-iscsi
  2. https://github.com/kubernetes-csi/csi-lib-fc
Ben Swartzlander of SIG storage looked in to creating a "common NFS library" but ultimately he recommended against it because such a library would just wrap a "mount" command. If you think it could still be useful to have a NFS library for CSI, I'd be happy to hear why, and we can create a "kubernetes-csi/csi-lib-nfs" if needed.

Also, FYI: In addition to creating libraries that CSI authors can import, SIG Storage also aims to provide basic but fully functional CSI drivers for these protocols (that import the libraries above to build a CSI driver):
These drivers are not yet complete. NFS and iSCSI were started here: https://github.com/kubernetes-csi/drivers/tree/master/pkg but need to be updated and moved to the final locations above. FibreChannel CSI driver hasn't been started at all, AFAIK. The purpose for these to to provide a standard off-the-shelf implementations.



--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/9707ecbd-5e7d-46e3-bd55-1c280d535f6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Calvin Hartwell

unread,
Jan 28, 2019, 8:31:06 PM1/28/19
to Saad Ali, panche...@gmail.com, kubernetes-sig-storage
Hi Cheng, Saad,

I think a CSI plugin for AWS EFS would be useful if it helped automate the EFS configuration/setup    on AWS, otherwise it would just be a wrapper for mount which wouldn’t make much sense; as you suggested. 

I have tested EFS with Kubernetes before the introduction of the CSI plugins and I have to say the performance was pretty terrible. I found that NetApp Trident with NetApp OnTap was a better solution with better performance and there is a CSI plugin already available. This setup can also be used in public clouds and on-prem. 

Cheers,

- Calvin 

Sent from my iPhone

Saad Ali

unread,
Jan 29, 2019, 1:40:37 PM1/29/19
to Calvin Hartwell, cheng pan, kubernetes-sig-storage
I agree. The mount code will be pretty much the same as any other NFS driver, but the provisioning code is going to be unique to AWS EFS, so I think it makes sense.

cheng pan

unread,
Jan 29, 2019, 5:48:34 PM1/29/19
to kubernetes-sig-storage
Hi Saad and Calvin,

Thanks for your inputs. 

Echo to Calvin's comment, implementing dynamic provisioning support for EFS is part of my plan. So I think this justifies its being a standalone driver. 

For the node service, another point is, since EFS provides its own mount extension `mount.efs` as the recommended client, this subtle difference will also cause difficulty to adapt implementation just for NFS client.

Cheng
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

Saad Ali

unread,
Jan 29, 2019, 9:17:38 PM1/29/19
to cheng pan, kubernetes-sig-storage
Makes sense!

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.

To post to this group, send email to kubernetes-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages