efs-provisioner

[pierluigilenoci]

I am opening this ticket because I wanted information about efs-provisioner. The repo that contained it has been archived https://github.com/kubernetes-retired/external-storage/ and I have not found any information on the future of the project. Can you help me? Maybe @wongma7 ?

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

[wongma7]

I recommend moving to https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner . It is a generic and less opinionated ( does not try to validate stuff) version of the efs provisioner

[pierluigilenoci]

I'll try this new provisioner. Thank you.

[chadlwilson]

Hi @wongma7 - do you know of a migration guide/suggestion/procedure somewhere for transitioning from the efs-provisioner to the nfs-subdir-external-provisioner for those with existing production systems and existing PVCs/PVs?

I'm trying to assess what we might be getting into with such a migration to a supported option (c.f switching to the EFS CSI driver, which is obviously an alternative).

Do you have any useful experience to share from your perspective @pierluigilenoci ?

[pierluigilenoci]

@chadlwilson I'm sorry but I haven't started migrating to the new provider yet so my experience is limited. I am waiting for the migration of the chart before starting to do the job once. Ref: https://github.com/helm/charts/issues/21103

@verwilst is the chart maintainer, maybe he can help you better.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[pierluigilenoci]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[chadlwilson]

I had forgotten about this issue, however if anyone else comes across it, in our case we found the migration to nfs-subdir-external-provisioner relatively painless. Needed to install in parallel with a diff storage class, create new PVCs for the relevant apps, but were able to do so on the same underlying EFS volume, migrate apps across and then remove the old PVCs and PVs before uninstalling the efs-provisioner.

In our case we didn't have data stored here that we couldn't afford to lose, making it easier.

Couple of differences to note

• no longer requires AWS creds (so need for kube2iam etc)
• I found a hack to allow the new provisioner to 'adopt' the previous volumes under the efs storage class which seemed to work fine, BUT it involved losing control of configuration values in the storage class (since these are immutable) and did not seem a good idea so we created a new storage class and new volumes in the end.
• the new provisioner is distroless so better from a security perspective
• new provisioner supports archive-on-delete which has is a different default behaviour to the old one

A hacky migration strategy for those who cannot lose data may be to exec into the old provisioner and copy files from the old volume subdir to the new subdir, being careful about permissions (if the provisioner shares EFS volume it can see the subdirs created by the other provisioner, and it has a shell in the container).

[pierluigilenoci]

@chadlwilson to be honest we have migrated to Amazon EFS CSI Driver
Ref: https://github.com/kubernetes-sigs/aws-efs-csi-driver