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

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还是不够的,其他的资源对象会在后续中学习到。