3.9 KiB
Storageclass and PVC.
In this part, we need to use storageclass to implement dynamic binding. The definition of dynamic binding is to realize the action of PVC binding without editing PV by yourself, which is more efficient than editing PV to do static binding.
Deploy NFS provisioner.yaml on the Kubernetes. We already provided NFS provisioner file, so you only need to modify NFS server and NFS client's IP and mount directory folder location, as shown in Figure.1
Figure1. Example of provisioner.
After edit NFS provisioner, following this command to deploy and check your NFS provisioner, as shown in Figure.2
//deploy
kubectl create -f (your YAML file name)
// check your file
kubectl get deployment
Figure2. Example of deploy porvisioner.
Create storageclass.yaml, we already provided storageclass file so you no need to rewrite a new one, but if you want to modify your storageclass name, you can modify at the position of the red box in Figure.3
Figure3. Example of storageclass.
After edit storageclass, following this command to deploy and check your storageclass, as shown in Figure.4.
//deploy
kubectl create -f (your YAML file name)
// check your file
kubectl get storageclass
Figure4. Example of deploy storageclass.
Add NFS-client-provisioner as the authority source for NFS provisioner, we already provided ServiceAccount file so you no need to rewrite a new one. In Kubernetes, we use Role, RoleBinding, ClusterRole, ClusterRoleBinding is used to give the service account sufficient permissions to handle the work related to StorageClass and PersistentVolumeClaim (PVC).
Following the commands to deploy and check your serviceaccount, as shown in Figure.5
//deploy
kubectl create -f (your YAML file name)
// check your file
kubectl get ServiceAccount
Figure5. Example of deploy ServiceAccount.
Most of the settings are completed, you can deploy our test-claim to confirm whether the PVC will be created under the mount directory of the NFS server
Figure6. Example of test-claim.
Previous: Install and setup NFS