AWS环境K3S使用nfs-csi时NFS挂载超时Pod卡在ContainerCreating

排查思路（按优先级从高到低） #

• 先测基础网络连通性，不要先怀疑发行版或组件问题。在所有AWS侧k3s节点上执行nc -zv <NFS服务端IP> 2049验证NFS核心端口连通性，同时补测111（portmap）、20048（mountd）端口。Azure同VNet虚拟机默认端口放通规则比AWS宽松很多，同配置下Azure能通、AWS不通的场景里，90%是安全组、网络ACL没放通对应端口导致的，对应报错如下：

MountVolume.SetUp failed for volume "nfs" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

• 跳过CSI层直接验证OS原生挂载能力。在出问题的节点上执行mount -t nfs <NFS服务端IP>:<共享目录路径> /mnt/test，如果这条命令直接超时，问题和k3s、nfs-csi完全无关，只需要排查OS配置、网络策略即可。
  • 如果原生挂载失败，先检查NFS客户端依赖是否安装：Ubuntu节点执行apt update && apt install -y nfs-common，Amazon Linux节点执行yum install -y nfs-utils。Azure市场的Ubuntu镜像默认预装nfs-common，AWS官方提供的Ubuntu默认镜像不带这个包，是非常容易忽略的差异点。
• 排查nfs-csi组件适配问题。如果原生挂载能成功，执行kubectl logs -n kube-system -l app=nfs-csi-node -c nfs-plugin拉取nfs-csi节点插件日志，重点看两个配置点：一是daemonset里配置的kubelet根目录是否和k3s实际路径匹配，k3s默认kubelet路径为/var/lib/kubelet，部分旧版nfs-csi默认写死其他K8s发行版的kubelet路径会导致挂载卡住；二是nfs-csi-node Pod是否开启了特权模式，k3s默认安全限制下，没有特权权限的Pod无法执行mount系统调用。
• 检查AWS特有网络配置：如果NFS服务端是部署在EC2上的自建服务，需要关闭对应EC2网卡的源/目标地址检查，否则跨子网转发的NFS流量会被AWS直接丢弃，Azure同场景下默认不会拦截这类流量。

解决方案 #

• 网络规则修复：在k3s节点、NFS服务端关联的安全组中双向放通NFS相关端口（2049/TCP/UDP、111/TCP/UDP、20048/TCP/UDP），同时确认子网绑定的网络ACL没有拦截对应端口流量。
• 节点依赖统一：所有节点不管是Ubuntu还是Amazon Linux，统一预装对应版本的NFS客户端包，且提前在节点上验证原生NFS挂载成功后，再部署nfs-csi组件。
• CSI配置适配k3s：部署nfs-csi时明确指定kubelet目录挂载路径为/var/lib/kubelet，同时给nfs-csi-node的工作负载开启privileged: true特权权限。
• 无需强制更换操作系统：AWS支持提到的"不支持k3s"仅代表官方技术支持范围不覆盖第三方K8s发行版，不是技术层面无法运行，实测Ubuntu 20.04/22.04版本上部署k3s+nfs-csi在AWS环境可以稳定运行。

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