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