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

k8s之StorageClass

//执行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

k8s之StorageClass

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

//接下来我们查看一下pv,验证是否动态创建:
k8s之StorageClass

我们可以看到已经自动生成了一个关联的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

k8s之StorageClass

//我们进入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服务器的共享数据目录下查看文件是否同步:
k8s之StorageClass

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

k8s之StorageClass

我们进入到该目录下,可以看到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

k8s之StorageClass

k8s之StorageClass

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