K8s数据耐久化之主动创立PV

在前两篇结束k8s的数据耐久化的流程为:建立nfs底层存储===》创立PV====》创立PVC===》创立pod。究竟pod中的container结束数据的耐久化。

上述流程中,看似没什么问题,但细想一下,PVC在向PV央求存储空间的时分,是依据指定的pv称谓、拜访方法、容量巨细来选择详细向哪个PV来央求空间的,假定PV的容量为20G,界说的拜访方法是WRO(只允许以读写的方法挂载到单个节点),而PVC央求的存储空间为10G,那么一旦这个PVC是向上面的PV央求的空间,也便是说,那个PV有10个G的空间被浪费了,由于其只允许被单个节点挂载。就算不考虑这样的一个问题,咱们每次手动去创立PV也就比较费事的作业,这时,咱们就需要一个主动化的东西来替咱们创立PV。

这个东西便是阿里供给的一个开源镜像“nfs-client-provisioner”,这个东西是经过k8s内置的NFS驱动挂载远端的NFS服务器到本地目录,然后本身作为storage(存储)。

当然,PVC是无法直接去向nfs-client-provisioner央求运用的存储空间的,这时,就需要经过SC(storageClass)这个资源政策去央求了,SC的根柢效果便是依据PVC界说的值去主动创立PV。

下面是一个Nginx依据主动创立PV结束数据耐久化的示例。

1、建立nfs服务

为了便利,我这儿直接在master上做nfs。

[root@master ~]# yum -y install nfs-utils
[root@master ~]# systemctl enable rpcbind
[root@master lv]# mkdir -p /nfsdata
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl enable nfs-server
[root@master ~]# showmount -e
Export list for master:
/nfsdata *

2、创立rbac授权

这种主动创立pv的方法触及到了rbac授权。

[root@master ~]# vim rbac-rolebind.yaml    #创立rbac授权用户,在以下文件有必要指定称谓空间,哪怕是default
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
[root@master ~]# kubectl apply -f rbac-rolebind.yaml      #实施yaml文件

3、创立nfs-client-provisioner容器

[root@master ~]# vim nfs-deployment.yaml       #编写yaml文件
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nfs-client-provisioner
namespace: default
spec:
replicas: 1               #副本数量为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: ljz-test         #这是上面变量的值(姓名)
- name: NFS_SERVER       #内置变量,用于指定nfs服务的IP
value: 192.168.20.6
- name: NFS_PATH              #内置变量,指定的是nfs同享的目录
value: /nfsdata
volumes:              #这下面是指定上面挂载到容器内的nfs的途径及IP
- name: nfs-client-root
nfs:
server: 192.168.20.6
path: /nfsdata
[root@master ~]# kubectl apply -f nfs-deployment.yaml          #实施yaml文件

4、创立SC(StorageClass)

[root@master ~]# vim test-storageclass.yaml   #编写yaml文件
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: statefu-nfs
namespace: default
provisioner: ljz-test     #这儿要和第三个nfs-client-provisioner的env环境变量中的value值对应。
reclaimPolicy: Retain        #收回策略为:retain,还有一个默许的值为“default”
[root@master ~]# kubectl apply -f test-storageclass.yaml    #实施yaml文件

5、创立PVC

[root@master ~]# vim test-pvc.yaml      #编写yaml文件
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-claim
namespace: default
spec:
storageClassName: statefu-nfs                 #界说存储类的姓名,要和SC的姓名对应
accessModes:
- ReadWriteMany          #拜访方法为RWM
resources:
requests:
storage: 500Mi
[root@master ~]# kubectl apply -f test-pvc.yaml      #实施yaml文件
#检查是否主动创立了PV并为bound状况
[root@master ~]# kubectl get pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS   REASON   AGE
persistentvolume/pvc-355593f0-2dfd-4b48-a3c6-c58d4843bcf4   500Mi      RWX            Delete           Bound    default/test-claim   statefu-nfs             2m53s
NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/test-claim   Bound    pvc-355593f0-2dfd-4b48-a3c6-c58d4843bcf4   500Mi      RWX            statefu-nfs    2m53s

其实至此,咱们已结束了依据PVC的央求存储空间去主动创立PV(本地的nfs同享目录下现已生成了一个目录,姓名挺长的,是pv+pvc姓名界说的目录名),至于这个PVC央求的空间是给哪个pod运用,这现已无所谓了。

6、创立依据Nginx镜像的pod

[root@master ~]# vim nginx-pod.yaml   #编写yaml文件
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: myweb
namespace: default
spec:
replicas: 3
template:
metadata:
labels:
app: web
spec:
containers:
- name: myweb
image: nginx:latest
volumeMounts:
- name: myweb-persistent-storage
mountPath: /usr/share/nginx/html/
volumes:
- name: myweb-persistent-storage
persistentVolumeClaim:
claimName: test-claim           #这的姓名要和PVC的姓名一同
[root@master ~]# kubectl apply -f nginx-pod.yaml       #实施yaml文件

当实施上述的yaml文件后,nginx容器内的网页目录就和本地的nfs同享目录相关起来了。