External-storage: [aws-efs] efs-provisioner pod stuck at ContainerCreating state

[iboware]

Hi,
I tried multiple ways to deploy the efs-provisioner/aws-efs but It always gets stuck at ContainerCreating state.
That's the message I'm getting after timeout.

Error from server (BadRequest): container "efs-provisioner" in pod "efs-provisioner-6bbcb6564d-np5dx" is waiting to start: ContainerCreating

Unable to mount volumes for pod "efs-provisioner-6bbcb6564d-np5dx_default(fef46aa3-f591-11e8-9bd7-0a82e658de78)": timeout expired waiting for volumes to attach or mount for pod "default"/"efs-provisioner-6bbcb6564d-np5dx". list of unmounted volumes=[pv-volume]. list of unattached volumes=[pv-volume efs-provisioner-token-gcxd8] 

[guilleironhack]

I am having the exact same issue. Are there any news related to it?

[wongma7]

Check kubelet logs to see why mount is failing. Based on what is in your spec kubelet will do the mount e.g.

          nfs:
            server: fs-47a2c22e.efs.us-west-2.amazonaws.com
            path: /persistentvolumes

means kubelet will basically do mount -t nfs fs-47a2c22e.efs.us-west-2.amazonaws.com:/persistentvolumes so if for some reason that does not work from the node then the container will not start. You can ssh into the node and try to see if mount works manually. If not there is some efs configuration issue

[guilleironhack]

You were right, in my case there was a mismatch in the security groups between the EC2 instances and the EFS mount targets. Thank you!!

[joariasl]

In my case, the problem is that I have mounted the EFS in all the worker nodes. (kube-aws can mount the EFS in the /efs path by default)
I try to umount the NFS and it working now. (systemctl stop ef or /usr/bin/umount /efs)
Reference of the Reclaiming Resources process https://docs.okd.io/latest/install_config/persistent_storage/persistent_storage_nfs.html#nfs-reclaiming-resources

[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-testing, kubernetes/test-infra and/or fejta.
/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-testing, kubernetes/test-infra and/or fejta.
/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-testing, kubernetes/test-infra and/or fejta.
/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-testing, kubernetes/test-infra and/or fejta.
/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.

[edvegas]

Check security group of EFS to allow inbound port 2049 from appropriate resource, eg security group of EKS worker nodes

[yvinap]

I faced exactly same issue. I resolved the issue by removing persistentvolumes from the path.
Before:

nfs:
            server: fs-47a2c22e.efs.us-west-2.amazonaws.com
            path: /persistentvolumes

After:

nfs:
            server: fs-47a2c22e.efs.us-west-2.amazonaws.com
            path: /

If you want to indicate the specific folder (persistentVolumes in this case) then the folder need to be created first. Isn't it? Was that step mentioned in the readme that I might have missed?