如何解决EKS中FSx作为Windows节点持久化卷的挂载问题？

一、初始错误：csi.sock连接被拒绝（MountVolume.MountDevice失败） #

• 检查SMB CSI驱动的Windows节点组件状态：
  • 执行kubectl get pods -n kube-system，确认smb-csi-node-windows-xxx Pod处于Running状态
  • 若Pod未运行，查看日志排查启动问题：kubectl logs smb-csi-node-windows-xxx -n kube-system（常见原因：镜像拉取失败、节点权限不足）
• 验证csi.sock文件存在：
  • 远程登录Windows节点，检查路径C:\var\lib\kubelet\plugins\smb.csi.k8s.io\csi.sock是否存在
  • 若文件缺失，重启smb-csi-node-windows Pod，确保驱动组件正常安装
• 确认kubelet与CSI驱动的通信权限：
  • 检查Windows节点上kubelet进程是否拥有该sock文件的访问权限
  • 执行Get-Service kubelet，确认kubelet服务处于Running状态

二、修复连通性后新错误：New-SmbGlobalMapping失败（错误53：网络路径未找到） #

• 测试Windows节点到FSx SMB共享的网络连通性：
  • 执行ping FSx_id.AD_DNS_name，确认DNS解析正常且能连通目标地址
  • 若DNS解析失败，检查节点DNS配置是否指向AD DNS服务器，或直接用FSx IP测试：ping <FSx_IP>
  • 执行Test-NetConnection FSx_id.AD_DNS_name -Port 445，确认SMB端口（445）可正常访问
• 验证共享访问权限：
  • 确保挂载用的AD账号拥有该共享的读写权限
  • 在Windows节点手动测试挂载，排查权限问题：

    $secpasswd = ConvertTo-SecureString "你的密码" -AsPlainText -Force
    $mycreds = New-Object System.Management.Automation.PSCredential ("域名\用户名", $secpasswd)
    New-SmbGlobalMapping -RemotePath "\\FSx_id.AD_DNS_name\share" -Credential $mycreds
    

• 检查FSx共享配置：
  • 确认FSx for Windows File Server的共享已正确创建，共享名称与PV配置一致
  • 验证FSx所在VPC与EKS节点VPC网络连通，安全组允许445端口的出入站流量
• 核对PV/PVC配置：
  • 确认PV的source字段为//FSx_id.AD_DNS_name/share（格式用正斜杠或双反斜杠均可）
  • 检查存储类或PV关联的Secret包含正确的AD账号、密码和域名信息

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