如何在 Kubernetes 集群中设置动态 NFS 配置
NFS k8s
![](/data/attachment/album/202307/28/222834togtruhoeuh3gtr1.jpg)



> 
> 在这篇文章中，我们将向你展示如何在 Kubernetes（k8s）集群中设置动态 NFS 配置。
> 
> 
> 


Kubernetes 中的动态 NFS 存储配置允许你按需自动为 Kubernetes 应用配置和管理 NFS（网络文件系统）卷。它允许创建持久卷（PV）和持久卷声明（PVC），而无需手动干预或预配置存储。


NFS 配置程序负责动态创建 PV 并将其绑定到 PVC。它与 NFS 服务器交互，为每个 PVC 创建目录或卷。


### 先决条件


* 预装 Kubernetes 集群
* 具有 Kubernetes 集群管理员权限的普通用户
* 互联网连接


事不宜迟，让我们深入探讨步骤：


### 步骤 1、准备 NFS 服务器


就我而言，我将在 Kubernetes 主节点（Ubuntu 22.04）上安装 NFS 服务器。登录主节点并运行以下命令：



```
$ sudo apt update
$ sudo apt install nfs-kernel-server -y

```

创建以下文件夹并使用 NFS 共享它：



```
$ sudo mkdir /opt/dynamic-storage
$ sudo chown -R nobody:nogroup /opt/dynamic-storage
$ sudo chmod 777 /opt/dynamic-storage

```

在 `/etc/exports` 文件中添加以下条目：



```
$ sudo vi /etc/exports
/opt/dynamic-storage 192.168.1.0/24(rw,sync,no_subtree_check)

```

保存并关闭文件。


注意：不要忘记更改导出文件中适合你的部署的网络。


要使上述更改生效，请运行：



```
$ sudo exportfs -a
$ sudo systemctl restart nfs-kernel-server
$ sudo systemctl status nfs-kernel-server

```

![NFS-Service-Status-Kubernetes-Master-Ubuntu](/data/attachment/album/202307/28/223041bzx61xy1g16ktzsi.jpg)


在工作节点上，使用以下 `apt` 命令安装 `nfs-common` 包。



```
$ sudo apt install nfs-common -y

```

### 步骤 2、安装和配置 NFS 客户端配置程序


NFS 子目录外部配置程序在 Kubernetes 集群中部署 NFS 客户端配置程序。配置程序负责动态创建和管理由 NFS 存储支持的持久卷（PV）和持久卷声明（PVC）。


因此，要安装 NFS 子目录外部配置程序，首先使用以下命令集安装 `helm`：



```
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

```

运行以下命令来启用 `helm` 仓库：



```
$ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner

```

使用以下 `helm` 命令部署配置程序：



```
$ helm install -n nfs-provisioning --create-namespace nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=192.168.1.139 --set nfs.path=/opt/dynamic-storage

```

![helm-install-nfs-provisioning-kubernetes-cluster](/data/attachment/album/202307/28/223102j8wpwx1p7xmxzvpr.jpg)


上面的 `helm` 命令将自动创建 `nfs-provisioning` 命名空间，并安装 NFS 配置程序的容器荚/部署、名称为 `nfs-client` 的存储类，并将创建所需的 rbac。



```
$ kubectl get all -n nfs-provisioning
$ kubectl get sc -n nfs-provisioning

```

![kubectl-get-all-nfs-provisioning-kubernetes-cluster](/data/attachment/album/202307/28/223115t81slq74u9q8ddss.jpg)


完美，上面的输出确认了配置程序容器荚和存储类已成功创建。


### 步骤 3、创建持久卷声明（PVC）


让我们创建 PVC 来为你的容器荚或部署请求存储。PVC 将从存储类 `nfs-client` 请求特定数量的存储：



```
$ vi demo-pvc.yml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: demo-claim
  namespace: nfs-provisioning
spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi

```

保存并关闭文件。


![PVC-Yaml-Dynamic-NFS-Kubernetes](/data/attachment/album/202307/28/223127zwz9zy98yy80ity1.jpg)


运行以下 `kubectl` 命令以使用上面创建的 YML 文件创建 PVC：



```
$ kubectl create -f demo-pvc.yml

```

验证 PVC 和 PV 是否创建：



```
$ kubectl get pv,pvc -n nfs-provisioning

```

![Verify-pv-pvc-dynamic-nfs-kubernetes-cluster](/data/attachment/album/202307/28/223143i0jiziu2dnk2pi9z.jpg)


太好了，上面的输出表明 PV 和 PVC 创建成功。


### 步骤 4、测试并验证动态 NFS 配置


为了测试和验证动态 NFS 配置，请使用以下 YML 文件启动测试容器荚：



```
$ vi test-pod.yml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: nfs-provisioning
spec:
  containers:
  - name: test-pod
    image: busybox:latest
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && sleep 600"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: demo-claim

```

![Pod-Yml-Dynamic-NFS-kubernetes](/data/attachment/album/202307/28/223216ib8gmhkqzhmmagfq.jpg)


使用以下 `kubectl` 命令部署容器荚：



```
$ kubectl create -f test-pod.yml

```

验证 `test-pod` 的状态：



```
$ kubectl get pods -n nfs-provisioning

```

![Verify-Test-Pod-Using-NFS-Volume-Kubernetes](/data/attachment/album/202307/28/223241kwy855mbwz5jm5wb.jpg)


登录到容器荚并验证 NFS 卷是否已安装。



```
$ kubectl exec -it test-pod -n nfs-provisioning /bin/sh

```

![Access-Dynamic-NFS-Inside-Pod-Kubernetes](/data/attachment/album/202307/28/223252dsbotdzi1zoofcys.jpg)


太棒了，上面容器荚的输出确认了动态 NFS 卷已安装且可访问。


最后删除容器荚和 PVC，查看 PV 是否自动删除。



```
$ kubectl delete -f test-pod.yml
$ kubectl delete -f demo-pvc.yml
$ kubectl get pv,pvc -n  nfs-provisioning

```

![Delete-Pod-PVC-Dynamic-NFS](/data/attachment/album/202307/28/223303b51o55ou5oxo1xwl.jpg)


这就是这篇文章的全部内容，希望对你有所帮助。请随时在下面的评论部分发表你的疑问和反馈。


*（题图：MJ/75dae36f-ff68-4c63-81e8-281e2c239356）*




---


via: <https://www.linuxtechi.com/dynamic-nfs-provisioning-kubernetes/>


作者：[Pradeep Kumar](https://www.linuxtechi.com/author/pradeep/) 选题：[lkxed](https://github.com/lkxed/) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
In this post, we will show you how to setup dynamic nfs provisioning in Kubernetes (k8s) cluster.

Dynamic NFS storage provisioning in Kubernetes allows you to automatically provision and manage NFS (Network File System) volumes for your Kubernetes applications on-demand. It enables the creation of persistent volumes (PVs) and persistent volume claims (PVCs) without requiring manual intervention or pre-provisioned storage.

The NFS provisioner is responsible for dynamically creating PVs and binding them to PVCs. It interacts with the NFS server to create directories or volumes for each PVC.

#### Prerequisites

- Pre-installed Kubernetes Cluster
- A Regular user which has admin rights on Kubernetes cluster
- Internet Connectivity

Without any further delay, let’s deep dive into steps

## Step1) Prepare the NFS Server

In my case, I am going to install NFS server on my Kubernetes master node (Ubuntu 22.04). Login to master node and run following commands,

$ sudo apt update $ sudo apt install nfs-kernel-server -y

Create the following folder and share it using nfs,

$ sudo mkdir /opt/dynamic-storage $ sudo chown -R nobody:nogroup /opt/dynamic-storage $ sudo chmod 2770 /opt/dynamic-storage

Add the following entries in /etc/exports file

$ sudo vi /etc/exports /opt/dynamic-storage 192.168.1.0/24(rw,sync,no_subtree_check)

Save and close the file.

Note: Don’t forget to change network in exports file that suits to your deployment.

To make above changes into the effect, run

$ sudo exportfs -a $ sudo systemctl restart nfs-kernel-server $ sudo systemctl status nfs-kernel-server

On the worker nodes, install nfs-common package using following [apt command](https://www.linuxtechi.com/apt-command-ubuntu-debian-linux/).

$ sudo apt install nfs-common -y

## Step 2) Install and Configure NFS Client Provisioner

[NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) deploy the NFS client provisioner in your Kubernetes cluster. The provisioner is responsible for dynamically creating and managing Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) backed by NFS storage.

So, to install NFS subdir external provisioner, first install helm using following set of commands,

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 $ chmod 700 get_helm.sh $ ./get_helm.sh

Enable the helm repo by running following beneath command,

$ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner

Deploy provisioner using following helm command

$ helm install -n nfs-provisioning --create-namespace nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=192.168.1.139 --set nfs.path=/opt/dynamic-storage

Above helm command will automatically create nfs-provisioning namespace and will install nfs provisioner pod/deployment, storage class with name (nfs-client) and will created the required rbac.

$ kubectl get all -n nfs-provisioning $ kubectl get sc -n nfs-provisioning

Perfect, output above confirms that provisioner pod and storage class is created successfully.

## Step 3) Create Persistent Volume Claims (PVCs)

Let’s a create PVC to request storage for your pod or deployment. PVC will request for a specific amount of storage from a StorageClass (nfs-client).

$ vi demo-pvc.yml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: demo-claim namespace: nfs-provisioning spec: storageClassName: nfs-client accessModes: - ReadWriteMany resources: requests: storage: 10Mi

save & close the file.

Run following kubectl command to create pvc using above created yml file,

$ kubectl create -f demo-pvc.yml

Verify whether PVC and PV are created or not,

$ kubectl get pv,pvc -n nfs-provisioning

Great, above output shows that pv and pvc are created successfully.

## Step 4) Test and Verify Dynamic NFS Provisioning

In order to test and verify dynamic nfs provisioning, spin up a test pod using following yml file,

$ vi test-pod.yml kind: Pod apiVersion: v1 metadata: name: test-pod namespace: nfs-provisioning spec: containers: - name: test-pod image: busybox:latest command: - "/bin/sh" args: - "-c" - "touch /mnt/SUCCESS && sleep 600" volumeMounts: - name: nfs-pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: nfs-pvc persistentVolumeClaim: claimName: demo-claim

Deploy the pod using following kubectl command,

$ kubectl create -f test-pod.yml

Verify the status of test-pod,

$ kubectl get pods -n nfs-provisioning

Login to the pod and verify that nfs volume is mounted or not.

$ kubectl exec -it test-pod -n nfs-provisioning /bin/sh

Great, above output from the pod confirms that dynamic NFS volume is mounted and accessible.

In the last, delete the pod and PVC and check whether pv is deleted automatically or not.

$ kubectl delete -f test-pod.yml $ kubectl delete -f demo-pvc.yml $ kubectl get pv,pvc -n nfs-provisioning

That’s all from this post, I hope you have found it informative. Feel free to post your queries and feedback in below comments section.

RaScaThat’s a great how-to, many thanks!

Just would like to add a consideration about permissions. The NFS directory that we’re using here to share the content, so /opt/dynamic-storage, gets the number of the beast (at least in Linux): 777.

This can’t possibly be right. Those kind of permissions are too wide and a security risk, it can simply be avoided by using something like:

> sudo chown -R nobody:nogroup /storage

> sudo chmod 2770 /storage

The setgid does the trick here, and you don’t have a directory opened for rwx to the world.

With that said, the resources that get created by the provisioner are in any case 777:

> sudo ls -la /storage/

total 12

drwxrws— 3 nobody nogroup 4096 giu 9 12:24 .

drwxr-xr-x 22 root root 4096 giu 9 12:20 ..

drwxrwxrwx 2 nobody nogroup 4096 giu 9 12:25 nfs-provisioning-demo-claim-pvc-3483691c-492f-4a84-875d-897efe855978

But that’s how the provisioner work, and so should be explored there (the project doesn’t seem to be maintained anymore ‘https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/issues/286’ ).

Great work, btw!