Kubernetes集群worker节点部署的NFS Server Pod无法访问问题咨询

1. 验证ClusterIP连通性 #

kubelet挂载NFS卷是节点本地的mount进程发起请求，不是Pod内流量走CNI网络，所以先直接在worker节点本地测试NFS Service的连通性：

# 测试TCP端口连通性
telnet 10.100.171.36 2049
nc -zv 10.100.171.36 111
# 测试UDP端口连通性
nc -zvu 10.100.171.36 2049
nc -zvu 10.100.171.36 111

如果端口不通，优先排查worker节点的kube-proxy状态：

# 查看worker节点对应的kube-proxy pod是否正常运行
kubectl -n kube-system get pod -l k8s-app=kube-proxy | grep worker
# 查看kube-proxy日志是否有规则同步报错
kubectl -n kube-system logs <对应worker节点的kube-proxy pod名称>

kube-proxy的iptables/ipvs规则未同步是节点无法访问ClusterIP的最常见原因。

2. 验证NFS导出路径配置 #

你当前NFS Pod的启动参数是导出/exports目录，但PV中配置的挂载路径是/registry，需确认NFS Pod内已创建/exports/registry目录且导出规则正常：

# 进入NFS Pod查看导出配置
kubectl exec -it nfs-server-pod -- exportfs -v

输出需包含对应路径的导出规则，且允许所有来源访问，否则会触发挂载失败。

3. 替换Pod IP临时验证 #

你可以临时修改registry Pod的PV配置，将NFS服务器地址替换为NFS Pod的实际Pod IP：

# 查看NFS Pod的IP地址
kubectl get pod nfs-server-pod -o wide

如果用Pod IP可以正常挂载，即可确定问题出在Service转发链路，无需再排查NFS服务本身配置。

针对你的场景，推荐两种更稳定的部署方案，避免依赖ClusterIP转发的不稳定问题：

1. 使用HostNetwork部署NFS Pod
   给NFS Pod新增hostNetwork: true配置，直接复用worker节点的物理网络栈，PV中直接填写worker节点的物理IP作为NFS服务地址，无需额外配置Service，没有转发开销，性能最高。
2. 使用NodePort类型暴露NFS Service
   将NFS Service的type改为NodePort，PV中填写worker节点的物理IP+对应的NodePort端口，节点的mount请求直接走物理网络访问，不依赖集群CNI和kube-proxy规则，兼容性更好。

额外优化建议：在PV的NFS配置中新增挂载参数指定NFS版本，避免Debian 10默认NFS版本的兼容问题：

nfs:
  server: 你的NFS服务地址
  path: /registry
  mountOptions: ["nfsvers=4.1", "tcp"]

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