Kubernetes多命名空间下NFS隔离共享块设备的最佳方案问询

针对你用单节点挂载大容量块存储做NFS、为多K8s项目提供隔离存储的场景，我推荐优先采用外部单节点NFS服务器+K8s NetworkPolicy+命名空间级PV/PVC绑定的方案，这是当前最贴合需求、运维成本最低的最佳实践。下面我详细拆解为什么这个方案最优，以及如何解决你提到的安全顾虑，同时分析另一种思路的问题：

一、为什么不推荐多容器化NFS服务？ #

你提到的“在同一节点部署多个NFS服务器Pod”的思路，其实是得不偿失的：

• 资源浪费：每个NFS Pod都会占用节点的CPU、内存资源，哪怕是轻量的NFS镜像，多实例叠加也会浪费本来就有限的廉价VPS资源。
• 运维复杂度高：每个NFS Pod需要单独配置存储卷映射到大容量块的对应目录，还要处理端口冲突（默认NFS用2049端口，要么修改每个Pod的端口，要么用HostPort占用节点端口，管理起来非常麻烦）。
• 排查成本高：多个NFS服务在同一节点运行，日志、监控会分散，出现存储问题时很难快速定位到具体实例。

所以这个思路并不适合你的场景，完全没必要为了隔离而部署多份NFS服务。

二、外部NFS服务的安全隔离方案（解决你的核心顾虑） #

外部NFS服务的安全问题完全可以通过NFS导出配置+K8s NetworkPolicy+PV/PVC命名空间绑定三层机制来解决，实现每个NFS目录仅对对应命名空间的Pod开放：

1. NFS服务器侧的基础配置 #

首先在你的廉价VPS上完成NFS服务的部署和目录准备：

• 为每个项目创建独立的目录：mkdir -p /share/project1 /share/project2 ... /share/projectN
• 配置/etc/exports，允许整个K8s集群的Pod CIDR访问对应目录（因为Pod IP是动态的，直接限制Pod CIDR比单个IP更灵活），示例配置：

/share/project1  10.244.0.0/16(rw,sync,no_subtree_check,no_root_squash)
/share/project2  10.244.0.0/16(rw,sync,no_subtree_check,no_root_squash)

这里的10.244.0.0/16是默认的K8s Pod CIDR，替换成你集群的实际CIDR即可。执行exportfs -ra让配置生效。

2. K8s侧的NetworkPolicy隔离 #

通过NetworkPolicy限制只有对应命名空间的Pod能访问NFS服务器的2049端口，这是实现命名空间级隔离的关键。比如针对project1命名空间，创建如下NetworkPolicy：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nfs-access
  namespace: project1
spec:
  podSelector: {} # 匹配命名空间下所有Pod
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32 # 替换成你的NFS服务器IP
    ports:
    - protocol: TCP
      port: 2049
    - protocol: UDP
      port: 2049 # NFS部分操作会用到UDP，建议同时开放

这样一来，只有project1命名空间的Pod能访问NFS服务器，其他命名空间的Pod会被阻断，从网络层面实现了隔离。

3. 命名空间级PV/PVC绑定 #

为每个项目创建独立的PersistentVolume（PV），指向NFS服务器对应的目录，然后在对应命名空间创建PersistentVolumeClaim（PVC）绑定该PV：

• PV示例（project1）：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-project1
  labels:
    project: project1
spec:
  capacity:
    storage: 100Gi # 根据实际需求调整
  accessModes:
    - ReadWriteMany # NFS支持多Pod读写
  nfs:
    server: 192.168.1.100 # 替换成你的NFS服务器IP
    path: /share/project1
  persistentVolumeReclaimPolicy: Retain # 避免误删除数据

• PVC示例（project1命名空间）：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-project1
  namespace: project1
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  selector:
    matchLabels:
      project: project1 # 通过标签匹配对应的PV

完成后，只有project1命名空间的Pod可以使用这个PVC，实现了存储资源的命名空间级隔离。

三、进阶安全优化（可选） #

如果你的项目涉及敏感数据，可以启用NFSv4的Kerberos认证，结合K8s的ServiceAccount实现身份验证。不过这个配置相对复杂，适合对安全要求极高的场景，一般中小规模集群用上面的三层机制就足够了。

四、其他注意事项 #

• 确保NFS服务器和K8s集群之间的网络连通，开放2049端口（TCP+UDP）。
• 定期备份NFS服务器上的数据：因为单节点NFS存在单点故障风险，可以用定时任务（比如rsync）把数据同步到其他存储介质（哪怕是临时用对象存储做备份）。
• 如果集群Pod CIDR发生变化，及时更新NFS的/etc/exports配置并重新生效。

内容的提问来源于stack exchange，提问作者Manel R. Domènech