Kubernetes中StorageClass的使用方法

Storage Class资源

1，为什么要使用Storage Class？

• 之前常规的手动挂载，看似没有什么问题，但细想一下，pvc在向pv申请存储空间时，是根据指定的pv名称，访问模式，容量大小来决定具体向那个pv来申请空间的，假设pv的容量为20G，定义的访问模式是WRO（只允许以读写的方式挂载到单个节点），而pvc申请的存储空间为10G，那么一旦这个pvc是向上面的pv申请的空间，也就是说，那么pv有10个G的空间被浪费了，因为其只允许被单个节点挂载。就算不考虑这个问题，我们每次手动去创建pv也就比较麻烦的事情，这时，我们就需要一个自动化的工具来替我们创建pv。
• 这个东西就是阿里提供的一个开源工具“nfs-client-provisioner”，这个东西是通过k8s内置的nfs驱动将远端的NFS服务器挂载到本地目录，然后自身作为storage（存储）。

2，stroage class在集群中的作用？

• pvc是无法直接去向nfs-client-provisioner申请使用的存储空间的，这时，就需要通过SC这个资源对象去申请了，SC的根本作用就是根据pvc定义的来动态创建pv，不仅节省了我们管理员的时间，还可以封装不同类型的存储供pvc选用。

• 每个sc都包含以下三个重要的字段，这些字段会在sc需要动态分配pv时会使用到：

  Provisioner（供给方）：提供了存储资源的存储系统。
  ReclaimPolicy：pv的回收策略，可用的值有Delete（默认）和Retiain
  Parameters（参数）：存储类使用参数描述要关联到存储卷。

3，下面基于NFS服务来实践storage class
1）搭建NFS服务（我将master节点作为nfs server）：

[root@master ~]# yum -y install nfs-utils
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# mkdir /nfsdata    #创建共享目录
[root@master ~]# systemctl start rpcbind
[root@master ~]# systemctl enable rpcbind
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl enable nfs-server
[root@master ~]# showmount -e  #确保成功挂载
Export list for master:
/nfsdata *

2）创建rbac权限：
rbac（基于角色的访问控制），就是用户通过角色与权限进行关联。
是一个从认证-----> 授权-----> 准入机制。

[root@master sc]# vim rbac-rolebind.yaml 
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

//执行yaml文件：

[root@master sc]# kubectl apply -f  rbac-rolebind.yaml 
serviceaccount/nfs-provisioner created
clusterrole.rbac.authorization.k8s.io/nfs-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-provisioner created

以上我们新建的一个名为nfs-provisioner的ServiceAccount，然后绑定了一个名为nfs-provisioner-runner的ClusterRole，而该ClusterRole声明了一些权限，其中就包括对pv的增，删，改，查等权限，所以我们可以利用该serviceAccount来自动创建pv。

3）创建一个nfs的Deployment
将里面的对应的参数替换成我们自己的nfs配置。

[root@master sc]# vim nfs-deployment.yaml 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: default
spec:
  replicas: 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: nfs-deploy    #供给方的名称（自定义）
            - name: NFS_SERVER
              value: 172.16.1.30     #nfs服务器的ip地址
            - name: NFS_PATH
              value: /nfsdata      #nfs共享的目录
      volumes:  
        - name: nfs-client-root
          nfs:
            server: 172.16.1.30
            path: /nfsdata

//导入nfs-client-provisioner镜像（集群中的每个节点都需导入，包括master）

[root@master sc]# docker load --input  nfs-client-provisioner.tar 
5bef08742407: Loading layer  4.221MB/4.221MB
c21787dcfbf0: Loading layer  2.064MB/2.064MB
00376105a0f3: Loading layer  41.08MB/41.08MB
Loaded image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner:latest

//执行yaml文件：
[root@master sc]# kubectl apply -f  nfs-deployment.yaml 
deployment.extensions/nfs-client-provisioner created

//确保pod正常运行
[root@master sc]# kubectl  get pod 
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-5457694c8b-k8t4m   1/1     Running   0          23s

nfs-client-provisionser工具的作用：它通过k8s的内置的nfs驱动挂载远端的nfs服务器到本地目录，然后将自身作为storage provide（存储提供），关联sc。

4）创建storage class:

[root@master sc]# vim test-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: statefu-nfs
  namespace: default
provisioner: nfs-deploy  
reclaimPolicy: Retain

我们声明了一个名为statefu-nfs的sc对象，注意下面的provisioner字段对应的值一定要和上面的nfs的Deployment下面的PROVISIONER_NAME这个环境变量的值一样。

//创建该资源对象：

[root@master sc]# kubectl apply -f  test-sc.yaml 
storageclass.storage.k8s.io/statefu-nfs created

5）上面把SC资源对象创建成功了，接下来我们测试是否能够动态创建pv。
//首先我们创建一个pvc对象：

[root@master sc]# vim test-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim    
  namespace: default
spec:
  storageClassName: statefu-nfs   #sc一定要指向上面创建的sc名称
  accessModes:
    - ReadWriteMany   #采用ReadWriteMany的访问模式
  resources:
    requests:
      storage: 50Mi    #请求50M的空间

//执行yaml文件来创建pvc：

[root@master sc]# kubectl  apply -f  test-pvc.yaml 
persistentvolumeclaim/test-claim created

我们可以看到pvc创建成功，状态已经是Bound了，是不是也生产了一个对应的volume对象，最重要的一栏是STORAGECLASS，现在的值就是我们刚刚创建的sc对象名称”statefu-nfs“。

//接下来我们查看一下pv，验证是否动态创建：

我们可以看到已经自动生成了一个关联的pv对象，访问模式是RWX(在sc中定义的模式)，回收策略Delete ，状态同样是Bound，是通过sc动态创建的，而并不是我们手动创建的。

4，部署nginx来实践pv，pvc

我们通过部署一个nginx服务来测试我们上面用stroage class方式声明的pvc对象（实现数据持久化）。

[root@master sc]# vim nginx-pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: nginx-pod
  namespace: default
spec:
  containers:
    - name: nginx-pod
      image: nginx
      volumeMounts:    #定义数据持久化
        - name: nfs-pvc
          mountPath: /usr/share/nginx/html
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:   #指定pvc，注意下面声明的pvc指向的是上面定义的pvc名称
        claimName: test-claim   

//运行nginx，并查看pod是否正常运行：
[root@master sc]# kubectl apply -f  nginx-pod.yaml 
pod/nginx-pod created

//我们进入pod中，创建测试网页文件：

[root@master ~]# kubectl  exec  -it nginx-pod /bin/bash
root@nginx-pod:/# cd /usr/share/nginx/html/
root@nginx-pod:/usr/share/nginx/html# echo "<h2>welcome to Storage Class web</h2>" > index.html
root@nginx-pod:/usr/share/nginx/html# cat index.html 
<h2>welcome to Storage Class web</h2>
root@nginx-pod:/usr/share/nginx/html# exit

//我们回到nfs服务器的共享数据目录下查看文件是否同步：

在nfs目录下我们可以可以看到有名字很很长的文件夹，这个文件夹的命名方式就是我们上面的规则生成的。

我们进入到该目录下，可以看到nginx中的数据已经实现同步，且实现了数据持久化（这里就不做测试了，可自行测试）

最后测试nginx是否能够正常访问我们编写的网页：
//创建service资源对象，关联上边的pod，映射端口号。
一个完整的yaml文件内容如下：

kind: Pod
apiVersion: v1
metadata:
  name: nginx-pod
  namespace: default
  labels:
    app: web
spec:
  containers:
    - name: nginx-pod
      image: nginx
      volumeMounts:
        - name: nfs-pvc
          mountPath: /usr/share/nginx/html
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
spec:
  type: NodePort
  selector:
    app: web
  ports:
  - name: nginx
    port: 80
    targetPort: 80
    nodePort: 32134

//重新加载nginx，并访问网页：

[root@master sc]# kubectl  apply -f  nginx-pod.yaml 
pod/nginx-pod configured
service/nginx-svc created