EKS集群PVC呈Lost状态、PV呈Pending状态的调试求助

• 检查EFS挂载目标与EKS节点网络连通性

  • 确认EFS挂载目标的VPC和EKS集群VPC一致，且挂载目标部署在EKS节点所在的子网内
  • 在任意EKS节点上执行mount -t nfs4 <EFS文件系统ID>.efs.<区域>.amazonaws.com:/ /tmp/test-mount手动测试挂载，排查安全组、NACL是否阻断NFS协议端口（2049）

• 验证存储类配置正确性

  • 确认存储类的provisioner字段为efs.csi.aws.com，参数中的fileSystemId和你创建的EFS文件系统ID完全匹配
  • 执行kubectl get sc <存储类名称> -o yaml查看完整配置，核对volumeBindingMode（如果设为WaitForFirstConsumer，PV绑定会延迟到第一个pod调度时，但这里PVC直接报Lost，优先检查是否配置正确）、reclaimPolicy等参数
  • 确保PVC的storageClassName字段和目标存储类名称完全一致，PVC的resources.requests.storage设置了有效值（EFS不限制容量，但必须指定，比如1Gi）

• 排查EFS访问点配置

  • 登录AWS控制台确认EFS访问点关联的文件系统正确，若访问点指定了RootDirectory.Path，要确保该路径在EFS中已存在
  • 检查EFS访问点的POSIX权限是否允许EKS pod使用的服务账户对应的IAM角色访问，同时确认CSI控制器的IAM角色具备elasticfilesystem:DescribeAccessPoints、elasticfilesystem:CreateAccessPoint权限

• 查看集群事件与PV/PVC详细配置

  • 执行kubectl events查看集群内所有事件，除了PVC的ClaimLost警告，是否有PV创建、绑定阶段的异常日志
  • 即使PV状态为Pending，执行kubectl get pv <PV名称> -o yaml查看完整配置，检查是否存在字段缺失、配置错误的情况
  • 查看PVC的完整yaml：kubectl get pvc <PVC名称> -o yaml，确认volumeName是否已关联PV，以及是否有其他异常字段

• 验证CSI控制器与节点驱动状态

  • 确认EFS CSI控制器pod全部处于Running状态：kubectl get pods -n kube-system -l app=efs-csi-controller
  • 检查CSI控制器的服务账户是否通过IRSA关联了正确的IAM角色，确保角色拥有EFS相关操作权限（比如elasticfilesystem:DescribeFileSystems）
  • 重新过滤控制器日志中的PV相关内容：kubectl logs -n kube-system <控制器pod名称> -c efs-plugin | grep -i pv，即使之前没看到错误，也可能有细节被忽略
  • 确认节点上的EFS CSI驱动pod正常运行：kubectl get pods -n kube-system -l app=efs-csi-node，检查pod的挂载卷（/sys、/var/lib/kubelet）是否正常

内容的提问来源于stack exchange，提问作者user1