Azure的File Storage以前只支持SMB，所以aks也只支持SMB，随着NFS服务的发布和k8s发布CSI驱动，aks预览版也开始支持NFS。

与共享磁盘不同，NFS为aks提供了原生的NAS共享支持，pod或node之间无需仲裁，对非结构化数据环境里存储和计算的解耦提供了良好的解决方案。例如用aks做http服务器，可以将共用的config、静态页面等放入NFS，提供给前端container使用，这些文件做更新时，只需更新NFS上的单副本即可，无需对container轮流更新，简化了管理。
Azure不支持NFS时，需要手工搭建NFS Server，过程比较复杂，并且vm自身成为单点故障。现在则可直接在aks调用NFS服务。
原以为，aks配置NFS比共享磁盘简单，没想到遇到了一些坑，折腾一晚上才搞定。一定看文档，一定看文档，一定看文档，重要的事情说三遍！

环境搭建

参照前两篇文章激活Azure的NFS服务，创建支持CSI驱动的aks集群并添加到vs code（添加到vs code并不是必须，只是为了便于管理）：

并创建一个存储账户备用（可以和aks集群在一个资源组也可以不在，建议放入MC开头的资源组便于管理，类型必须是高级版FileStorage才支持NFS）：
az storage account create -g MC_aks-csi-rg_aks-csi-cluster_westus2 -n aksnfs --sku Premium_LRS --kind FileStorage -l westus2 -o table

如果只是普通使用，很简单，将NFS的连接字串直接放到volumns配置就可以了。但是，如果希望通过PVC调用动态卷，就需要对存储账户进行配置。
文档里的描述如下：

这里有两个地方需要对存储账户配置：一是禁用https，二是必须使用指定网络，并将aks node的网络加入。
测试的时候，我认为不配置存储账户不配置防火墙时，默认所有网络均可访问，不会影响。没想到就是这么一个简单问题，一直导致不成功。所以一定要注意。
存储账户配置修改完成后如下：

创建NFS

创建NFS StorageClass

首先还是通过yaml文件创建NFS StorageClass。
创建内容如下名为nfs-class.yaml的文件：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
  resourceGroup: MC_aks-csi-rg_aks-csi-cluster_westus2
  storageAccount: aksnfs
  protocol: nfs

其中，如果和aks集群在一个资源组，可以不用填写资源组；存储账户填入预先准备的放置NFS共享的存储账户。
应用此文件：

检查StorageClass，可以看到新建的StorageClass：

创建NFS数据卷

创建内容如下名为nfs-pvc.yaml的文件：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  resources:
    requests:
      storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi-nfs

注意，高级FileStorage要求的最小容量是100Gi，所以这里storage的参数不能小于100Gi
应用此文件：

创建完成后，到存储账户里可以看到自动生成了共享，协议是NFS：

使用nfs

创建如下名为nfs-deploy.yaml文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfsdemo
spec:
  selector:
    matchLabels:
      app: nfsdemo
  template:
    metadata:
      labels:
        app: nfsdemo
    spec:
      containers:
      - name: nfsdemo
        image: busybox
        volumeMounts:
          - mountPath: /mnt
            name: nfsshare 
      volumes:
        - name: nfsshare
          persistentVolumeClaim:
            claimName: nfs-pvc

注意，此处附件nfs的参数是volumeMounts，而不是附加磁盘用的volumeDevices.
应用此文件：

用如下命令检查pvc的使用情况：
kubectl describe persistentvolumeclaims nfs-pvc

可以看到已经被pod使用。

后续

可能大家会有疑问，为什么要用这么复杂的pvc的方式，而不去container直接mount数据卷？
考虑一个场景，存储的管理通常是运维负责，而k8s的配置则是应用开发管理。如果直接使用container mount的方式，无论是数据卷的创建、容量修改还是销毁等操作，都需要运维参与。特别是在生产过程中的变更，很繁琐。
而pvc的方式，则把存储管理交给应用开发，可以按需随时配置，这即是IaaC（Infra as a code）的一种实现方式，方便了从应用到底层的生命周期管理。
刚才我们看了如何用code去生成并mount存储。下边看看销毁过程。
先看看现有的数据卷pv情况：
kubectl get persistentvolume