k8s-基于nfs创建静态provisioner和基于StorageClass根据PVC动态生成PV并绑定

k8s-基于nfs创建静态和动态pv,pvc

以下的操作都经过实际测试，如果遇到问题可以留言。
前置条件：
部署k8s集群（节点node-1, node-2,node-3）部署k8s集群的教程

k8s中三个node节点，node-1为master,node-2,node-3为子节点

一：nfs服务器部署

1.1 所有节点安装nfs

yum install -y nfs-utils rpcbind

1.2 所有服务器启动nfs服务

#手动加载 NFS 共享服务时，应该先启动 rpcbind，再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启，rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind

1.3 创建共享目录，并授权

mkdir /root/data/nfs
chmod 777 /root/data/nfs

1.4 编辑 exports 文件

vim /etc/exports
/root/data/nfs 192.168.81.0/24(rw,no_root_squash,sync)
#保存退出 
:wq

1.5 执行export

exportfs -rv//重新export一次 

1.6 查看本机的共享目录

showmount -e

若是需要重新修改/etc/exports文件，需要执行以下命令重新运行文件即可

exportfs -rv

二. 静态 Provisioning 例子-操作演示

2.1创建PV

	定义一个pv,也可以定义多个PV，本次是测试主机上是否能够成功创建pv以及绑定pvc。
	注意：共享目录以及主机IP改成自己的。 

2.1.1 创建PV文件

vim pv_nfs.yaml	

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 1Gi
  #指定访问模式
  accessModes:
    #pv能以readwrite模式mount到单个节点
    - ReadWriteOnce
  #指定pv的回收策略,即pvc资源释放后的事件.retain(建议,使用动态供给代替)保留pvc的所有文件
  persistentVolumeReclaimPolicy: Retain
  #指定pv的class为nfs,相当于为pv分类,pvc将指定class申请pv
  storageClassName: mynfs
  #指定pv为nfs服务器上对应的目录
  nfs:
    path: /root/data/nfs
    server: 192.168.81.140

2.1.2 创建后再查看：

kubectl apply -f pv_nfs.yaml #创建
kubectl get pv #查看

2.2： 定义pvc

定义 PVC 申请的大小为 2Gi, storageClassName指定class申请pv，进行绑定bound。

vim pvc.nfs.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfspvc1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: mynfs

2.2.1 发布以及查看

kubectl apply -f pvc_nfs.yaml
kubectl get pvc

2.3：创建应用资源,使用pvc存储

2.3.1 编辑应用资源配置文件：

vim pvjob.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pvjob
spec:
  template:
    spec:
      containers:
      - name: bbox1
        image: busybox
        args:
        - /bin/sh
        - -c
        - echo "hello pv" > /mydata/hello
        volumeMounts:
        - mountPath: "/mydata"
          name: mydata
      restartPolicy: Never
      volumes:
      - name: mydata
        persistentVolumeClaim:
          claimName: nfspvc1

该job将在nfs的volume创建一个hello文件,打印”hello pv”字符串

2.3.2: 应用该Job资源

创建该job,并查看实验结果：

kubectl apply -f pvjob.yaml #创建该job资源
cat /root/data/nfs/hello  #查看实验结果

2.3.3 删除job资源

删除job资源后，查看hello文件是否在共享目录中保存下来了。使用 “Retain” 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。

根据上面的结果，可以知道hello文件并没有随pvc的删除，hello文件而删除掉。

三. 基于storageclass的动态 Provisioning 例子-操作演示

StorageClass概述

StorageClass 为管理员提供了描述存储 "类" 的方法，实现了存储的动态供给，简单来说，StorageClass能够根据pvc来自动创建pv，减轻了集群管理员创建pv的负担。

创建一个StorageClass需要以下几部分：

provisioner：StorageClass能够自动创建pv的前提是我们给StorageClass指定一块可以使用的存储，provisioner即定义了StorageClass使用哪块存储。

RBAC： 这里定义了StorageClass需要的权限。

StorageClass: 定义StorageClass存储类，并且说明使用哪一个provisioner

3.1 nfs服务器配置修改

3.1.1 创建共享目录

mkdir /data

3.1.2 编辑exports文件

vim /etc/exports
/data 192.168.81.4/24(rw,no_root_squash,sync) #192.168.81.0/24即可
#保存退出 
:wq

/data :是共享的目录
192.168.81.4 是nfs服务器的IP地址，这个只需要在主机同一网段下面即可。可以为一个网段，一个IP，也可以是域名，域名支持通配符 如: *.qq.com
             IP 网络— 允许在更大的网络中根据其 IP 地址匹配主机。例如， 192.168.0.0 / 28 允许前 16 个 IP 地址（从 192.168.0.0 到 192.168.0.15）访问导出的文件系统，但不允许访问 192.168.0.16 及更高版本。
rw/ro 权限是读写或只读 (read-only)，但最终能不能读写，还是与文件系统的 rwx 及身份有关。
no_root_squash 登入 NFS 主机使用分享目录的使用者，如果是 root 的话，那么对于这个分享的目录来说，他就具有 root 的权限，单词squash是压缩压扁的意思。
sync/async: sync代表数据会同步写入到内存与硬盘中，async 则代表数据会先暂存于内存当中，而非直接写入硬盘！

3.1.3 重新加载export文件

修改了/etc/exports后，并不需要重启nfs服务，只要用exportfs重新扫描一次/etc/exports，并且重新加载即可exportfs[-aruv] 。

exportfs -rv//重新export一次 
exportfs -au//全部卸载 

3.2 StorageClass创建过程

3.2.1 创建RBAC的yaml文件

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

执行ServiceAccount文件

kubectl apply -f rbac.yaml

3.2.2 创建provisioner的yaml文件

apiVersion: apps/v1
kind: Deployment # provisioner的类型是一个deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  namespace: default # 指定provisioner所属的namespace，改成你自己的namespace
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner # 指定provisioner使用的sa
      containers:
        - name: nfs-client-provisioner
          image: vbouchaud/nfs-client-provisioner:latest # 指定provisioner的镜像
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes # 固定写法
          env:
            - name: PROVISIONER_NAME
              value: scm-storage-class # 指定分配器的名称，创建storageclass会用到
            - name: NFS_SERVER
              value: 192.168.81.140 # 指定使用哪一块存储，这里用的是nfs，此处填写nfs的地址
            - name: NFS_PATH
              value: /data # 使用nfs哪一块盘符
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.81.140 # 和上面指定的nfs地址保持一致
            path: /data # 和上面指定的盘符保持一致

执行文件provisioner

kubectl apply -f provisioner.yaml 

查看是否部署成功

 kubectl get deploy -n default

如果READY一直都是0/1，就是没有部署成功，可以通过以下命令来查看出错的信息，并根据出错的信息进行修改，修改后再次部署即可。

kubectl describe deploy nfs-client-provisioner -n ${你的namespace名称}

部署出现的问题

部署时遇到的问题：
1. 主机IP和storageclass的Name一定要改成自己的设置。
2. namespace也需要修改成自己的命名空间
3. 特别注意：共享盘符与自己创建共享目录需要一致，不然会出现无法创建的错误。

3.2.3 创建storageclass

准备storageclass.yaml文件

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: scm-storage # storageclass的名字
provisioner: scm-storage-class # 必须与provisioner.yaml中PROVISIONER_NAME的值一致
parameters:
  archiveOnDelete: "true"  ## 删除pv的时候，pv的内容是否要备份
allowVolumeExpansion: true  #如果对PVC扩容，则其对应的"storage class"中allowVolumeExpansion字段需要设置成true：

文件创建完成后，执行创建命令

kuebctl apply -f storageclass.yaml

查看已经创建好的StorageClass:

kubectl get storageclass

3.3 创建成功后，创建一个pvc进行测试

创建scm-pvc.yaml，进行测试已经创建好的StorageClass，检查StorageClass是否创建好了pv。进行动态绑定。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: scm-pvc
  namespace: default
spec:
  storageClassName: scm-storage # 需要与上面创建的storageclass的名称一致
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

执行该文件：

kubectl apply -f scm-pvc.yaml

查看pvc和pv的部署情况：

kubectl get pvc -n default
kubectl get pv -n default

我们看到已经有一个新的 PV 生成，这个 PV 其实就是根据我们提交的 PVC 以及PVC 里面指定的storageclass 动态生成的。之后k8s会将生成的 PV 以及我们提交的 PVC，就是这个 scm PVC 做绑定，之后我们就可以通过创建 pod 来使用了。

如果pvc的状态是Pending或者其他状态，执行以下命令查看异常原因：

kubectl describe pvc scm-pvc -n ${你的namespace名称}

创建pod.yaml

pod yaml 很简单，也是通过 PVC 声明，表明使用这个 PVC。然后是挂载点，下面我们可以创建看一下。

vim pod,yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-pv-demo
  namespace: default
spec:
  containers:
  - name: scm-pod
    image: ubuntu:18.04
    volumeMounts:
      - name: scm-pvc
        mountPath: /data
    command: [ "sleep" , "3600s" ]
  volumes:
    - name: scm-pvc
      persistentVolumeClaim:
        claimName: scm-pvc

可以查看一下Events，首先被调度器调度，调度完之后（使用阿里云云盘接下来会有个 attachdetach controller，它会去做 disk的attach操作，就是把我们对应的 PV 挂载到调度器调度的 node 上）然后Pod对应的容器才能启动，启动容器才能使用对应的盘。

接下来我会把 PVC 删掉，看一下PV 会不会根据我们的storageclass中的 --reclaimPolicy：回收策略，Delete（默认的）和Retain（删除pvc针对pv的处理过程） – reclaimPolicy 随之删掉呢？我们先看一下，这个时候 PVC 还是存在的，对应的 PV 也是存在的。

然后删一下 PVC，删完之后再看一下：我们的 PV 也被删了，也就是说根据 reclaimPolicy，我们在删除 PVC 的同时，PV 也会被删除掉。

部署出现的问题：

部署pvc时出现目录权限不足，而无法创建目录的问题
经过查看，可以将exports文件中rw后加上no_root_squash字段，既可以成功创建部署。

结束