有时候我们会在本地环境中使用 kubernetes，这时候想要一些方便的类似 aws 和 其他公有云上那种 storage class 就不太可能了，这时候一般我们会选择使用 linux NFS 来代替这些共有云的存储卷
如果不需要storage class的话，直接使用docker run也是可以的，但是这里，因为我很懒，我希望在 NFS 创建之后能自动得到一个 storage class，那最方便的实际上是 rancher 提供的 helm，注意这里
nfs-client-provisioner 和 nfs-server-provisioner 只是驱动模式不同，功能是一样的
K8S的外部NFS驱动，可以按照其工作方式（是作为NFS server还是NFS client）分为两类：
NFS client 通过K8S的内置的NFS驱动挂载远端的NFS服务器到本地目录；然后将自身作为storage provider，关联storage class。当用户创建对应的PVC来申请PV时，该provider就将PVC的要求与自身的属性比较，一旦满足就在本地挂载好的NFS目录中创建PV所属的子目录，为Pod提供动态的存储服务
NFS server 与 nfs-client 不同，该驱动并不使用 k8s 的 NFS 驱动来挂载远端的 NFS 到本地再分配，而是直接将本地文件映射到容器内部，然后在容器内使用 ganesha.nfsd 来对外提供 NFS 服务；在每次创建 PV 的时候，直接在本地的 NFS 根目录中创建对应文件夹，并 export 出该子目录。利用 NFS 动态提供 Kubernetes 后端存储卷
可惜这里我使用的是 NFS-provisioner https://github.com/kubernetes-retired/external-storage
直接点击安装没什么好说得，注意默认的 node 上存储路径是 /srv，至于存储到哪个node上，这里是随机的，也可以通过node name 指定
可以看到这里我的 workload 被分配在了 139 上，
这种方式最方便的点在于可以直接得到 storage class
然后我们尝试安装一个 nginx 来使用这个 nfs-provisioner
然后我会在 nginx的pod上，使用 shell 在 /test 路径上创建一个测试文件
可以看到这个文件可以在 nfs node 上被找到
