k8s之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 "<h1>welcome to Storage Class web</h1>" > index.html
root@nginx-pod:/usr/share/nginx/html# cat index.html 
<h1>welcome to Storage Class web</h1>
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

nginx网页正常访问，部署完毕，以上就是Storage Class的使用方法，生产环境中仅有storage class仍是不够的，其余的资源对象会在后续中学习到。