K8s集群PVC无法绑定EFS静态/动态PV问题排查

问题环境 #

• 集群架构：基于EC2实例构建的Kubernetes集群，集群子网到EFS卷的安全组访问策略已全放通
• 变更记录：近期完成版本升级，Kubernetes从1.18升级至1.21，EFS CSI驱动从0.3升级至1.2.1
• 现状：同配置、同网络策略的存量静态EFS卷可正常绑定，新增EFS卷绑定持续失败

操作过程与问题现象 #

静态PV创建 #

首先创建未加密EFS卷，使用如下配置创建静态PersistentVolume：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "test"
spec:
  capacity:
    storage: "500Gi"
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: aws-efs
  csi:
    driver: efs.csi.aws.com
    volumeHandle: "fs-01b79fe9a42a2d166"

应用配置后PV成功创建，状态如下：

test            500Gi      RWX            Retain           Available                                   aws-efs                 5m12s

疑问：将volumeHandle修改为不存在的EFS文件系统ID时，PV依然可以创建成功，如何校验PV是否正确关联到目标EFS卷？

静态PVC绑定失败 #

尝试创建PersistentVolumeClaim绑定上述PV，配置如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    volume.beta.kubernetes.io/storage-provisioner: efs.csi.aws.com
  name: test
  namespace: prometheus
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: aws-efs
  volumeMode: Filesystem
  volumeName: test

PVC一直处于Pending状态，事件报错如下：

Events:
  Type     Reason                Age                   From                                                                           Message
  ----     ------                ----                  ----                                                                           -------
  Normal   Provisioning          9m9s                  efs.csi.aws.com_cluster-k8s-mgr-01_babd61df-c93b-448f-8169 External provisioner is provisioning volume for claim "prometheus/test"
  Warning  ProvisioningFailed    9m9s                  efs.csi.aws.com_cluster-k8s-mgr-01_babd61df-c93b-448f-8169 failed to provision volume with StorageClass "aws-efs": rpc error: code = InvalidArgument desc = Missing provisioningMode parameter
  Normal   ExternalProvisioning  3m1s (x26 over 9m9s)  persistentvolume-controller                                                    waiting for a volume to be created, either by external provisioner "efs.csi.aws.com" or manually created by system administrator

动态供给测试失败 #

尝试使用动态供给方案，首先创建StorageClass：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-04d246c34ff38f892
  directoryPerms: "700"

随后创建对应PVC：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 20Gi

PVC依旧处于Pending状态，事件报错如下：

Events:
  Type     Reason              Age    From                                                                           Message
  ----     ------              ----   ----                                                                           -------
  Normal   Provisioning        6m55s  efs.csi.aws.com_cluster-k8s-mgr-01_babd61df-c93b-448f-8169 External provisioner is provisioning volume for claim "default/efs-claim"
  Warning  ProvisioningFailed  6m55s  efs.csi.aws.com_cluster-k8s-mgr-01_babd61df-c93b-448f-8169 failed to provision volume with StorageClass "efs-sc": rpc error: code = Internal desc = Failed to fetch File System info: describe File System failed: NoCredentialProviders: no valid providers in chain. Deprecated.
           For verbose messaging see aws.Config.CredentialsChainVerboseErrors
  Normal   ExternalProvisioning  52s (x26 over 6m55s)  persistentvolume-controller  waiting for a volume to be created, either by external provisioner "efs.csi.aws.com" or manually created by system administrator

解决方案 #

1. 静态PV与EFS关联有效性校验 #

静态PV创建时Kubernetes API Server仅校验配置格式合法性，不会主动调用AWS API校验volumeHandle对应的EFS资源是否存在，可通过两种方式校验：

• 实际挂载验证：创建临时测试Pod挂载该PV，进入Pod执行df -h确认EFS挂载点正常，在挂载目录创建测试文件后，到AWS控制台查看对应EFS卷的挂载连接数、文件列表是否匹配，即可确认关联是否正确。
• 日志校验：查看EFS CSI Node、Controller组件的日志，确认挂载请求中传递的文件系统ID与目标EFS ID一致，无参数透传错误。

2. 静态PVC报Missing provisioningMode修复 #

该报错核心是静态PV场景下的StorageClass与PVC配置冲突：

• 静态PV不需要EFS CSI Provisioner执行卷创建操作，删除PVC上的volume.beta.kubernetes.io/storage-provisioner: efs.csi.aws.com注解，避免Kubernetes误触发动态供给流程。
• 静态PV使用的aws-efs StorageClass不要配置provisioningMode、fileSystemId等动态供给专属参数，仅需指定provisioner: efs.csi.aws.com即可。
• 统一PV与PVC的访问模式：当前PV配置为ReadWriteMany，PVC配置为ReadWriteOnce，静态绑定时需确保两边访问模式、存储容量、StorageClass名称完全匹配，避免绑定校验失败。

3. 动态供给报NoCredentialProviders修复 #

该报错说明EFS CSI Controller组件没有获取到调用AWS EFS API的合法权限，结合版本升级背景，按以下优先级排查：

• 权限适配：EFS CSI驱动从1.0版本开始调整了权限模型，0.x版本的旧IAM权限不适配1.2.1版本。如果使用EC2节点角色授权，给节点实例角色补充EFS操作权限，包括elasticfilesystem:DescribeFileSystems、elasticfilesystem:CreateAccessPoint、elasticfilesystem:DescribeAccessPoints、elasticfilesystem:TagResource等动态供给所需权限；如果使用IRSA（服务账号角色）授权，确认efs-csi-controller关联的服务账号是否正确配置了IAM角色注解，升级过程中旧的服务账号配置可能被覆盖。
• 运行状态校验：确认EFS CSI Controller的Pod正常运行，没有调度到无EFS访问权限的节点上，查看Controller Pod日志确认是否存在EC2元数据服务访问不通、凭证文件挂载失败的问题。

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