K8s进阶之PersistentVolumeClaim 动态供给
先来简单看一下这张图实现的过程，然后我们再来研究一下
成都创新互联公司主要业务有网站营销策划、成都做网站、网站制作、微信公众号开发、小程序制作、成都h5网站建设、程序开发等业务。一次合作终身朋友，是我们奉行的宗旨；我们不仅仅把客户当客户，还把客户视为我们的合作伙伴，在开展业务的过程中，公司还积累了丰富的行业经验、营销型网站建设资源和合作伙伴关系资源，并逐渐建立起规范的客户服务和保障体系。
说在前面的话，静态供给的话，会需要我们手动去创建pv，如果没有足够的资源，找不到合适的pv，那么pod就会处于pending等待的状态，就是说找不到合适的伴侣了，
所以解决这两种问题，就给出了这种动态供给，主要是能够自动帮你创建pv
，就是你需要多大的容量，就自动给你创建多大的容量，也就是pv，k8s帮你创建了，创建pvc的时候就需要找pv了，这个时候就交给这个存储类了，而存储类呢，去帮你创建这些pv,存储类呢，就是实现了对指定存储的一个支持，直接帮你去调用api去创建存储类，所以就不需要人工的去帮你创建pv了。
而你去想想，当节点比较多，业务比较多的时候，再去人工手动创建pv，量还是很大的，而且也不是很好去维护。
而动态供给主要的一个实现就是StorageClass存储对象，其实它就是声明你使用哪个存储，然后呢帮你去连接，再帮你去自动创建pv。举个例子更好去理解
话不多说上图
其实它是一个基于NFS实现的一个pv供给，它大概流程是这样的，我们可能会创建一个statefulset有状态的应用存储，然后有一个管理的nfs-storageClass，因为nfs目前是不支持这个自动的创建pv的，我们可以利用社区实现的插件来完成这个pv的自动创建，也就是StorageClass这一块，创建完之后，然后pod再去引用。
这个是kubernetes支持的动态供给的存储插件
https://kubernetes.io/docs/concepts/storage/storage-classes/
这里面呢会告诉你哪些存储支持哪些不支持，支持的话就不用使用社区的存储类了，如果不支持就要去找社区的存储类了，打钩的都是支持的，没打钩的就是不支持的。
这个是那个社区给我们提供的插件，来看一下
https://github.com/kubernetes-incubator/external-storage
K8s默认是不支持的，我们可以使用这个nfs-client这里面提供的yaml,社区开发的一个组件，这个组件能帮你自动创建PV，在deploy里面，我们会用到class，这个就会声明了你使用
哪个存储，哪个提供的，它会以一个应用的方式部署起来，另外一个会用到的就是rbac,
这个存储类会访问API,所以要为他定义RBAC授权策略,还有deployment，它是定义了以组件的形式部署起来，这个组件里面会有一个镜像，直接下载这个镜像就可以了，它可以帮我们自动的去创建pv，其实就是它来做的，如果k8s支持的话，就直接去调了，但k8s对NFS没有支持，所有需要使用这么个社区的组件来实现了，这里会定义NFS服务器的地址还有数据卷的来源
现在我们演示一下：
声明这里的yaml文件可以去刚才我发的社区地址当下来
[root@k8s-master demo]# mkdir nfs-client
[root@k8s-master demo]# cd nfs-client/
[root@k8s-master nfs-client]# rz -E
rz waiting to receive.
[root@k8s-master nfs-client]# ls
class.yaml deployment.yaml rbac.yaml先创建一下rbac，这里也不用定义，直接创建就可以了[root@k8s-master nfs-client]# kubectl create -f rbac.yaml
这里需要修改一个我们NFS服务器的地址以及NFS服务器的挂载目录
[root@k8s-master nfs-client]# vim deployment.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: nfs-client-provisioner
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: zhaocheng172/nfs-client-provisioner:latest
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: fuseim.pri/ifs
- name: NFS_SERVER
value: 192.168.30.27
- name: NFS_PATH
value: /opt/k8s
volumes:
- name: nfs-client-root
nfs:
server: 192.168.30.27
path: /opt/k8s
[root@k8s-master nfs-client]# kubectl create -f class.yaml
[root@k8s-master nfs-client]# kubectl create -f deployment.yaml 这里提供者就是fuseim.pri/ifs，在我们的class里面可以看到，storage需要告知使用者，使用者部署应用到k8s中，想使用这个自动供给，你必须告知它，它需要你在yaml文件里声明这个提供者，那就意味着提供者storageclass可以配置多个，可以是NFS，另一个是Ceph,另一个是云存储，都可以可以多个，只要它在创建应用时指定使用哪个storageclass，它就会在指定在哪个存储上创建自动pv
[root@k8s-master nfs-client]# kubectl get storageclass
managed-nfs-storage fuseim.pri/ifs 51s
[root@k8s-master nfs-client]# kubectl get pod
NAME READY STATUS RESTARTS AGE
my-pod 1/1 Running 0 18h
nfs-744d977b46-dh9xj 1/1 Running 0 18h
nfs-744d977b46-kcx6h 1/1 Running 0 18h
nfs-744d977b46-wqhc6 1/1 Running 0 18h
nfs-client-provisioner-fbc77b9d4-kkkll 1/1 Running 0 27s现在我们就可以使用pv的自动供给了
现在我们来测试一下，我在我原有的静态pod之上，在pvc上加上storageclass的名字
指定我们的存储类
为了测试我们实现自动供给，我们把原来的静态供给删除掉
[root@k8s-master nfs-client]# kubectl get pv,pvc
persistentvolume/zhaocheng 5Gi RWX Retain Released default/my-pvc 18h
persistentvolume/zhaochengcheng 10Gi RWX Retain Available 18h
[root@k8s-master nfs-client]# kubectl delete persistentvolume/zhaocheng
persistentvolume "zhaocheng" deleted
[root@k8s-master nfs-client]# kubectl delete persistentvolume/zhaochengcheng
persistentvolume "zhaochengcheng" deleted
[root@k8s-master nfs-client]# kubectl get pv,pvc
No resources found.这是我们动态供给的yaml格式，在pvc去指定我们的存储类storageClassName:
"managed-nfs-storage"
[root@k8s-master nfs-client]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: my-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
storageClassName: "managed-nfs-storage"
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
[root@k8s-master nfs-client]# kubectl create -f pod.yaml 查看我们的pv,pvc已经自动帮我们去创建，就不用我们手动再去创建pv了
[root@k8s-master nfs-client]# kubectl get pod
my-pod 1/1 Running 0 110s
nfs-744d977b46-dh9xj 1/1 Running 0 18h
nfs-744d977b46-kcx6h 1/1 Running 0 18h
nfs-744d977b46-wqhc6 1/1 Running 0 18h
nfs-client-provisioner-fbc77b9d4-kkkll 1/1 Running 0 20m
[root@k8s-master nfs-client]# kubectl get pv,pvc
persistentvolume/pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a 5Gi RWX Delete Bound default/my-pvc managed-nfs-storage 67s
NAME STATUS VOLUME
persistentvolumeclaim/my-pvc Bound pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a 5Gi RWX managed-nfs-storage 67s而在我们nfs服务器上也能看到pvc的目录，现在我们就可以去用了
[root@localhost k8s]# ls
default-my-pvc-pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a wwwroot zhaocheng zhaochengcheng
[root@localhost k8s]# cd default-my-pvc-pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a/
[root@localhost default-my-pvc-pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a]# ls
[root@localhost default-my-pvc-pvc-a24d4a5e-8f9d-4478-bfe5-b86e2360ae5a]# echo "hello persistentvolumeclaim" > index.html查看我们的容器pod
[root@k8s-master nfs-client]# kubectl exec -it my-pod bash
root@my-pod:/# cat /usr/share/nginx/html/index.html
hello persistentvolumeclaim
