在Kubernetes集群中部署NFS Subdir External Provisioner的完整复盘

在Kubernetes（K8s）的持久化存储体系中，NFS（Network File System）作为经典的共享存储方案，被广泛用于多Pod共享数据的场景。但手动创建NFS类型的PV（PersistentVolume）不仅繁琐，还难以适配动态扩容的需求。NFS Subdir External Provisioner 正是解决这一问题的利器——它能基于NFS服务器，为PVC（PersistentVolumeClaim）动态创建PV，并自动管理NFS子目录的生命周期。

本文将结合实战操作，从环境介绍、核心原理、分步部署、功能验证四个维度，完整复盘NFS Subdir External Provisioner的部署与使用流程，帮你快速落地K8s的NFS动态存储方案。

一、实战环境介绍

本次部署基于一套可正常运行的K8s集群，核心环境信息如下：

关键前提：NFS服务器已完成共享配置，K8s所有节点均可正常挂载该NFS共享目录。

二、核心原理讲解

1. NFS Subdir External Provisioner 是什么？

它是K8s官方维护的外部存储Provisioner，基于NFS协议实现动态PV供给。核心能力是：

• 监听K8s中PVC的创建/删除事件；
• 为每个PVC在NFS共享目录下自动创建独立子目录，并生成对应的PV；
• 当PVC删除时，根据配置归档或删除NFS子目录，实现PV的生命周期管理。

2. 动态PV的核心流程

1. 用户创建PVC：指定关联的StorageClass（绑定NFS Provisioner）；
2. Provisioner监听：检测到PVC创建请求，触发PV创建逻辑；
3. NFS子目录创建：在NFS共享目录/nfs-storage/k8s-pvs下，生成以命名空间-PVC名称-随机串命名的子目录；
4. PV创建与绑定：Provisioner创建PV，指向该NFS子目录，并与PVC完成绑定；
5. PVC删除回收：删除PVC时，Provisioner根据archiveOnDelete参数，将NFS子目录重命名为archived-xxx（归档）或直接删除。

3. StorageClass的作用

StorageClass是动态PV的“模板”，本次部署中我们创建了名为nfs-storage-class的StorageClass，核心配置包括：

• provisioner：指定为NFS Subdir External Provisioner；
• nfs.server/nfs.path：NFS服务器IP与共享目录；
• archiveOnDelete：PVC删除时是否归档NFS子目录（本次设为true）；
• defaultClass：是否设为集群默认StorageClass（本次设为true，未指定storageClassName的PVC将自动使用该类）。

三、实战部署步骤

步骤1：环境分析与前置准备

首先通过命令检查集群与NFS环境，确保部署前提满足：

# 1. 检查K8s节点状态
kubectl get nodes

# 2. 检查现有StorageClass（确认无冲突）
kubectl get storageclass

# 3. 检查Helm安装状态（初始未安装）
helm list -A

# 4. 安装Helm（通过snap快速安装）
sudo snap install helm --classic

# 5. 验证NFS服务器共享目录可用性
showmount -e 192.168.99.22

执行结果：NFS共享目录/nfs-storage/k8s-pvs正常暴露，Helm安装完成，K8s集群状态正常。

步骤2：Helm部署NFS Subdir External Provisioner

借助Helm仓库快速部署Provisioner，简化配置与管理：

# 1. 添加NFS Provisioner的Helm仓库
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/

# 2. 更新Helm仓库索引
helm repo update

# 3. 安装Provisioner（指定NFS参数、StorageClass配置）
helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
  -n kube-system \
  --set nfs.server=192.168.99.22 \
  --set nfs.path=/nfs-storage/k8s-pvs \
  --set storageClass.name=nfs-storage-class \
  --set storageClass.defaultClass=true

• -n kube-system：将Provisioner部署在K8s系统命名空间，便于管理；
• --set参数：核心配置NFS服务器、共享路径、StorageClass名称及默认属性。

步骤3：验证Provisioner部署状态

部署完成后，检查Provisioner与StorageClass的运行状态：

# 1. 检查Provisioner Pod状态（确认Running）
kubectl get pods -n kube-system | grep nfs-provisioner

# 2. 检查StorageClass（确认创建成功且为默认）
kubectl get storageclass

# 3. 查看StorageClass详细配置（验证参数正确性）
kubectl describe storageclass nfs-storage-class

执行结果：Provisioner Pod处于Running状态，nfs-storage-class StorageClass创建成功并标记为(default)，核心参数与NFS配置一致。

步骤4：验证动态PV功能

通过创建测试PVC，验证动态PV的创建、绑定、回收全流程：

（1）创建测试PVC YAML

新建test-nfs-pvc.yaml，定义PVC的存储需求与关联的StorageClass：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-nfs-pvc
  namespace: ms-demo  # 测试命名空间（需提前存在）
spec:
  accessModes:
    - ReadWriteMany  # NFS支持多Pod读写
  resources:
    requests:
      storage: 100Mi  # 申请100Mi存储
  storageClassName: nfs-storage-class  # 关联部署的StorageClass

（2）创建PVC并验证绑定

# 1. 创建PVC
kubectl apply -f test-nfs-pvc.yaml

# 2. 检查PVC状态（确认Bound）
kubectl get pvc -n ms-demo

# 3. 检查PV（确认自动创建并绑定）
kubectl get pv | grep test-nfs-pvc

执行结果：PVC状态为Bound，PV自动创建且与PVC完成绑定。

（3）验证NFS子目录创建

登录NFS服务器，检查共享目录下是否生成对应子目录：

ssh 192.168.99.22 "ls -la /nfs-storage/k8s-pvs/"

执行结果：生成ms-demo-test-nfs-pvc-xxx格式的子目录，证明Provisioner已成功创建NFS存储目录。

（4）验证PVC删除与PV回收

# 1. 删除测试PVC
kubectl delete -f test-nfs-pvc.yaml

# 2. 检查PV（确认自动删除）
kubectl get pv | grep pvc-xxx  # 替换为实际PV名称

# 3. 检查NFS子目录（确认归档）
ssh 192.168.99.22 "ls -la /nfs-storage/k8s-pvs/"

执行结果：PV被自动删除，NFS子目录重命名为archived-ms-demo-test-nfs-pvc-xxx（因archiveOnDelete=true，数据被归档保留）。

四、部署结果与注意事项

1. 核心验证结果

✅ NFS Subdir External Provisioner Pod正常运行（kube-system命名空间）； ✅ nfs-storage-class StorageClass创建成功并设为集群默认； ✅ 动态PV功能生效：PVC创建→PV自动创建→NFS子目录生成； ✅ 回收策略生效：PVC删除→PV自动删除→NFS子目录归档。

2. 关键注意事项

1. NFS权限配置：NFS共享目录需赋予K8s节点读写权限，避免Provisioner创建子目录失败；
2. archiveOnDelete参数：生产环境建议设为true（归档数据），测试环境可设为false（直接删除）；
3. 命名空间管理：Provisioner部署在kube-system，PVC需在目标命名空间创建（如本次ms-demo）；
4. 默认StorageClass：设为默认后，未指定storageClassName的PVC将自动使用NFS存储，需避免冲突；
5. NFS服务器稳定性：NFS服务器需保证高可用，否则会影响所有依赖该存储的Pod。

五、总结

通过Helm部署NFS Subdir External Provisioner，我们快速实现了K8s集群的NFS动态PV供给，彻底告别了手动创建PV的繁琐流程。从环境准备、Provisioner部署，到动态PV的创建、绑定、回收全流程验证，整套方案具备部署简单、管理高效、兼容性强的特点，非常适合中小型K8s集群的共享存储场景。

后续可基于该方案，为应用（如数据库、中间件、文件服务）配置持久化存储，结合ReadWriteMany访问模式，实现多Pod共享数据的需求，进一步提升K8s集群的存储管理效率。

本文转至：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzcwMTA1NjQyNQ==&action=getalbum&album_id=4350369381197905931#wechat_redirect