Amazon EKS使用Terraform配置NFS卷挂载到Kubernetes Pod失败求助

核心问题1：Deployment未关联PVC #

你导出的实际运行的Deployment YAML中可以看到，victoriametrics-data卷被配置为emptyDir: {}，属于Pod本地临时存储，完全没有关联你提前创建的PVC，这是卷未挂载成功的直接原因。
该问题源于你的Terraform kubernetes_deployment 资源配置缺失：volume块仅声明了卷名，没有指定关联的PVC。

修复方案 #

修改Terraform的Deployment配置，补充PVC关联配置：

resource "kubernetes_deployment" "victoriametrics" {
...
      spec {
        container {
          image = var.image
          name  = var.name
          ...
          volume_mount {
              mount_path        = "/data"
              mount_propagation = "None"
              name              = "victoriametrics-data"
              read_only         = false
            }
        }

        volume {
            name = "victoriametrics-data"
            # 新增以下PVC关联配置
            persistent_volume_claim {
              claim_name = kubernetes_persistent_volume_claim.victoriametrics.metadata.0.name
            }
        }

      }
    }
...
}

重新apply Terraform配置后，Deployment会重建Pod，自动挂载PVC对应的存储。

其他潜在问题排查 #

如果你修复上述配置后仍挂载失败，按以下步骤排查：

1. 确认PV/PVC状态正常
   执行命令kubectl get pv,pvc -n victoriametrics，确认PVC状态为Bound，且绑定的PV名称和你创建的一致。如果状态为Pending，检查StorageClass、PV的配置是否匹配。

2. CSI驱动命名不规范问题
   你创建的EFS CSI驱动名称为${local.cluster_name}-${local.namespace}，不符合AWS EFS CSI驱动的标准命名要求efs.csi.aws.com，会导致存储置备逻辑异常。如果你使用EFS CSI驱动挂载，需要将CSI驱动名称改为标准值，同时StorageClass的storage_provisioner也要对应改为efs.csi.aws.com。
   如果你是用原生NFS协议挂载，不需要部署EFS CSI驱动，可以直接删除该资源，同时确认所有EKS工作节点都安装了NFS客户端包（nfs-utils for Amazon Linux 2/AL2023，nfs-common for Debian/Ubuntu）。

3. PV配置冲突问题
   你当前PV使用nfs类型的源，对应原生NFS挂载逻辑，如果要使用EFS CSI驱动挂载，需要将PV的源改为CSI类型，示例如下：

persistent_volume_source {
  csi {
    driver = "efs.csi.aws.com"
    volume_handle = local.efs_file_system_id # 替换为你的EFS文件系统ID
  }
}

4. 查看Pod挂载事件
   执行kubectl describe pod <你的VictoriaMetrics Pod名称> -n victoriametrics，查看Events字段的报错信息，可以直接定位挂载失败的具体原因，比如网络不通、权限不足、客户端缺失等。

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