K8s数据持久化之自动创建PV

在前两篇实现k8s的数据持久化的流程为：搭建nfs底层存储===》创建PV====》创建PVC===》创建pod。最终pod中的container实现数据的持久化。

上述流程中，看似没什么问题，但细想一下，PVC在向PV申请存储空间的时候，是根据指定的pv名称、访问模式、容量大小来决定具体向哪个PV来申请空间的，如果PV的容量为20G，定义的访问模式是WRO（只允许以读写的方式挂载到单个节点），而PVC申请的存储空间为10G，那么一旦这个PVC是向上面的PV申请的空间，也就是说，那个PV有10个G的空间被浪费了，因为其只允许被单个节点挂载。就算不考虑这个问题，我们每次手动去创建PV也就比较麻烦的事情，这时，我们就需要一个自动化的工具来替我们创建PV。

这个东西就是阿里提供的一个开源镜像“nfs-client-provisioner”，这个东西是通过k8s内置的NFS驱动挂载远端的NFS服务器到本地目录，然后自身作为storage（存储）。

当然，PVC是无法直接去向nfs-client-provisioner申请使用的存储空间的，这时，就需要通过SC（storageClass）这个资源对象去申请了，SC的根本作用就是根据PVC定义的值去自动创建PV。

下面是一个Nginx基于自动创建PV实现数据持久化的示例。

1、搭建nfs服务

为了方便，我这里直接在master上做nfs。

[root@master ~]# yum -y install nfs-utils
[root@master ~]# systemctl enable rpcbind
[root@master lv]# mkdir -p /nfsdata
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl enable nfs-server
[root@master ~]# showmount -e
Export list for master:
/nfsdata *

2、创建rbac授权

这种自动创建pv的方式涉及到了rbac授权。

[root@master ~]# vim rbac-rolebind.yaml    #创建rbac授权用户，在以下文件必须指定名称空间，哪怕是default

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-provisioner
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nfs-provisioner-runner
  namespace: default
rules:
   -  apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
   -  apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
   -  apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
   -  apiGroups: [""]
      resources: ["events"]
      verbs: ["watch", "create", "update", "patch"]
   -  apiGroups: [""]
      resources: ["services", "endpoints"]
      verbs: ["get","create","list", "watch","update"]
   -  apiGroups: ["extensions"]
      resources: ["podsecuritypolicies"]
      resourceNames: ["nfs-provisioner"]
      verbs: ["use"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
[root@master ~]# kubectl apply -f rbac-rolebind.yaml      #执行yaml文件

3、创建nfs-client-provisioner容器

[root@master ~]# vim nfs-deployment.yaml       #编写yaml文件

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: default
spec:
  replicas: 1               #副本数量为1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccount: nfs-provisioner       #指定账户
      containers:
        - name: nfs-client-provisioner
          image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner   #使用的是这个镜像
          volumeMounts:
            - name: nfs-client-root
              mountPath:  /persistentvolumes      #指定容器内的挂载目录
          env:
            - name: PROVISIONER_NAME        #这是这个容器内置的变量
              value: ljz-test         #这是上面变量的值（名字）
            - name: NFS_SERVER       #内置变量，用于指定nfs服务的IP
              value: 192.168.20.6            
            - name: NFS_PATH              #内置变量，指定的是nfs共享的目录
              value: /nfsdata
      volumes:              #这下面是指定上面挂载到容器内的nfs的路径及IP
        - name: nfs-client-root
          nfs:
            server: 192.168.20.6
            path: /nfsdata
[root@master ~]# kubectl apply -f nfs-deployment.yaml          #执行yaml文件

4、创建SC（StorageClass）

[root@master ~]# vim test-storageclass.yaml   #编写yaml文件

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: statefu-nfs
  namespace: default
provisioner: ljz-test     #这里要和第三个nfs-client-provisioner的env环境变量中的value值对应。
reclaimPolicy: Retain        #回收策略为：retain，还有一个默认的值为“default”

[root@master ~]# kubectl apply -f test-storageclass.yaml    #执行yaml文件

5、创建PVC

[root@master ~]# vim test-pvc.yaml      #编写yaml文件

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim
  namespace: default        
spec:
  storageClassName: statefu-nfs                 #定义存储类的名字，要和SC的名字对应
  accessModes:
    - ReadWriteMany          #访问模式为RWM
  resources:
    requests:
      storage: 500Mi
[root@master ~]# kubectl apply -f test-pvc.yaml      #执行yaml文件
#查看是否自动创建了PV并为bound状态
[root@master ~]# kubectl get pv,pvc 
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS   REASON   AGE
persistentvolume/pvc-355593f0-2dfd-4b48-a3c6-c58d4843bcf4   500Mi      RWX            Delete           Bound    default/test-claim   statefu-nfs             2m53s

NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/test-claim   Bound    pvc-355593f0-2dfd-4b48-a3c6-c58d4843bcf4   500Mi      RWX            statefu-nfs    2m53s

其实至此，我们已经实现了根据PVC的申请存储空间去自动创建PV（本地的nfs共享目录下已经生成了一个目录，名字挺长的，是pv+pvc名字定义的目录名），至于这个PVC申请的空间是给哪个pod使用，这已经无所谓了。

6、创建基于Nginx镜像的pod

[root@master ~]# vim nginx-pod.yaml   #编写yaml文件

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myweb
  namespace: default
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: myweb
        image: nginx:latest
        volumeMounts:
        - name: myweb-persistent-storage
          mountPath: /usr/share/nginx/html/
      volumes:
      - name: myweb-persistent-storage
        persistentVolumeClaim:
          claimName: test-claim           #这的名字要和PVC的名字一致
[root@master ~]# kubectl apply -f nginx-pod.yaml       #执行yaml文件

当执行上述的yaml文件后，nginx容器内的网页目录就和本地的nfs共享目录关联起来了。