Containers-roadmap: [EKS] [request]: EFS CSI driver automatically provision EFS directory or access point

[chasmosis]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
We are migrating to EKS from another kubernetes on AWS and where we are using EFS with the EFS provisioner which automatically provisioned an EFS directory for PV/PVC on EFS. When investigating utilizing EFS on EKS it is suggested to use the EFS CSI driver rather than the EFS provisioner however we are finding that all of the EFS CSI driver documentation calls for a step of manually creating the EFS directory or an EFS access point.

From our viewpoint this is a loss of functionality moving from the EFS provisioner to the current EFS CSI driver.

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Ultimately we would like to minimize the local teams requirement to manually create underlying storage structures when provisioning of an EFS PV/PVC. Much like the creation of a gp2 pv using the aws-ebs provisioner creates the underlying ebs volume.

Are you currently working around this issue?
We are weighing between utilizing the older EFS provisioner vs the EFS CSI Driver as is vs writing our own automation to provision the efs directory or efs access point to utilize with the EFS CSI driver.

Additional context
Anything else we should know?

Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[devkid]

We started looking into using EFS on EKS and stumbled upon the same problem.

Our team is managing EKS clusters for other teams, isolated by namespaces. Using the CSI driver would mean for us:

• teams would need to provision their own EFS filesystems and / or provision their own PVs (which are not namespaced, so teams would need to have cluster-level write permissions for this, which is scary)
  or
• we would need to "pre-provision" a large amount of PVs to satisfy potential PVCs (which sounds off)

[chasmosis]

@devkid have you made any decisions on using EFS in your implementation?
We are in the same boat managing kubernets clusters for other teams. At this point if we are going to utilize EFS on EKS we will have to back away from the CSI driver and implement the EFS provisioner

https://github.com/kubernetes-incubator/external-storage/tree/master/aws/efs

Funny enough pretty much exactly like it is discussed in the EKS workshop:

https://eksworkshop.com/beginner/190_efs/efs-provisioner/

[mercantiandrea]

Same here, we switched back to the efs-provisioner for the same reason.
To use EFS CSI driver it should automate, at least, the provisioning of EFS access points.

[KarstenSiemer]

Me too. We've been quite confused as to why that wasn't implemented from the start, since thats what one should want for their clusters.
Is somebody able to make a guess when this will be implemented?
Apparently it is already planned according to this.
It's kinda hard to argue in favor for the provisioner since it is deprecated 🤷‍♂️

[haofeif]

efs-provisioner

@mercantiandrea Were you referring to this link
https://github.com/kubernetes-retired/external-storage/tree/master/aws/efs

Looks like it was in the "kubernetes-retired" status, and was never updated since Dec 11, 2019.

[whereisaaron]

Same as the rest, we looked at the CSI driver a couple times but it's not yet sufficient to replace efs-provisioner. Probably you could write an operator with CRD wrapper for the CSI driver to bridge the gaps. But that is significantly more complicated than the more elegant efs-provisioner solution. So we are sticking with that while we wait for the CSI driver to mature.

At a minimum, a user should be able to create a PVC, have it provisioned, and use it. That's not possible with the current CSI EFS implementation.

[paalkr]

It's seems just wrong that the EFS CSI driver project didn't include a provisioner from the start. I would been a natural component to actually make the EFS CSI driver useful in a cloud Native context.

However, I would just like to mention this project https://github.com/LogMeIn/aws-efs-csi-pv-provisioner, which does exactly whats requested in this feature request.

[ckdarby]

@mikestef9 Once the dynamic provisioning in place I feel that this CSI driver would be a good candidate as an EKS add-on?

[mikestef9]

Agreed, please open a separate issue with that request

[woodcockr]

Adding my voice to the “me too” list. Nothing more to add to the observations made, just hoping more votes might help with prioritisation.

[mikestef9]

You can see the in progress pull request here that will add the capability of dynamically provisioning access points. This will soon be merged and available in the next release of the EFS CSI driver