持久化存储PV与PVC

1.PV与PVC

PV：

持久卷（PersistentVolume）简称PV，是集群中的一块存储，可以由管理员事先供应。
可以配置NFS、Ceph等常用存储配置，相对于volumes，提供了更多的功能，如生命周期管理、大小的限制。
PV 卷的供应有两种方式：静态供应或动态供应。

静态：
集群管理员预先创建许多PV，在PV的定义中能够体现存储资源的特性。

动态：
集群管理员无须预先创建PV，而是通过StorageClass的设置对后端存储资源进行描述，标记存储的类型和特性。用户通过创建PVC对存储类型进行申请，系统将自动完成PV的创建及与PVC的绑定。如果PVC声明的Class为空""，则说明PVC不使用动态模式。

PVC：

持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。就像Pod消耗Node的资源一样，PVC消耗PV资源。PVC可以申请存储空间的大小（size）和访问模式。

由管理员创建PV连接到后端存储，使用人员或管理员创建PVC使用PV资源。

2.PV资源回收

当用户不再使用其存储卷时，他们可以从 API 中将 PVC 对象删除，从而允许 该资源被回收再利用。PV 对象的回收策略告诉集群，当其被 从申领中释放时如何处理该数据卷。 目前，数据卷可以被 Retained（保留）、Recycled（回收）或 Deleted（删除）。

Retain：保留资源

保留策略可以管理员手动回收资源，当PVC被删除后，PV仍然存在，对应的数据卷被视为"已释放（released）"，管理员可以手动回收资源。

Delete：删除数据

需要插件支持，如果支持，那么删除PVC时也会自动删除PV和相关的后端存储资源；动态卷默认为delete。

Recycle：回收（弃用）

回收策略已被弃用，代替者为动态供应。如果下层的卷插件支持，回收策略 Recycle 会在卷上执行一些基本的 擦除（rm -rf /thevolume/*）操作，之后允许该卷用于新的 PVC 申领。

3.访问模式

ReadWriteOnce：

卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷，缩写为RWO。

ReadOnlyMany：

卷可以被多个节点以只读方式挂载，缩写为ROX。

ReadWriteMany：

卷可以被多个节点以读写方式挂载，缩写为RWX。

ReadWriteOncePod：

卷可以被单个 Pod 以读写方式挂载。 如果你想确保整个集群中只有一个 Pod 可以读取或写入该 PVC， 请使用ReadWriteOncePod 访问模式。这只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本，缩写为RWOP。

注意： 你的存储支不支持这种访问模式，具体情况查看：官方文档

4.存储分类

文件存储（Filesystem）：

一些数据可能需要多个节点使用，比如用户头像、用户上传文件等，实现方式：NFS、NAS、FTP等；NFS和FTP不推荐。

块存储（block）：

一些数据只能被一个节点使用，或者是一块裸盘整个挂载使用，比如数据库、redis等，实现方式是Ceph、GlusterFS、公有云等。

对象存储：

由程序代码直接实现的一种存储方式，云原生应用无状态化常用的实现方式；实现方式：一般是符合53标准的云存储，比如AWS的53存储、Minio等。

5.创建PV卷

列举两个实例，其他类型可参考官网，因为我这资源有限。

5.1.实例：创建NAS/NFS类型的PV

生产不推荐NFS。可以使用NAS。

准备一台NFS服务器

第一步：准备一台NFS服务器，我这个装的有点多，你也可以只安装nfs服务器

[root@localhost ~]# yum -y install nfs* rpcbind

第二步：所有节点安装nfs客户端，不然不能识别，每一个需要挂载nfs的节点都需要装

[root@k8s-master01 ~]# yum -y install nfs-utils

第三步：在服务端创建共享目录

[root@localhost ~]# mkdir -p /data/k8s

第四步：服务端配置共享目录

[root@localhost ~]# cat /etc/exports
/data/k8s/ *(rw,sync,no_subtree_check,no_root_squash)
[root@localhost ~]# exportfs -r
[root@localhost ~]# systemctl restart nfs rpcbind

第五步：有另外一台机器挂载共享目录测试是否成功

[root@k8s-master01 hgfs]# mount -t nfs 192.168.10.6:/data/k8s /mnt
[root@k8s-master01 mnt]# mkdir hah
[root@k8s-master01 mnt]# ls
111.txt  hah
# 在nfs服务端查看
[root@localhost k8s]# ls
111.txt  hah

创建一个PV

第一步：编写一个PV的yaml文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs-slow
  nfs:
    path: /data/k8s
    server: 192.168.10.6

对上面的yaml文件做一下说明：

• 通用的开头就不说了
• capacity：容量配置，这个pv使用多大容量，当然需要后端存储支持才行
• volumeMode：卷的模式，目录4有说明
• accessModes：PV的访问模式，目录3有说明
• accessClassName：PV的类，特定的PV只能绑定特定的PVC
• persistentVolumeReclaimPolicy：回收策略，目录2有说明
• nfs：NFS服务配置，里面包含共享目录和服务端IP

第二步：执行yaml文件创建此PV；注意PV的成功跟后端存储正不正常没什么关系。

[root@k8s-master01 ~]# kubectl create -f pv-nfs.yaml 
persistentvolume/pv-nfs created
[root@k8s-master01 ~]# kubectl get pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-nfs   2Gi        RWO            Recycle          Available           nfs-slow                54s

第三步：说一下PV的状态（STATUS）

• Available：可用，没有被PVC绑定的空闲资源
• Bound：已绑定，已经被PVC绑定
• Released：已释放，PVC被删除，资源未被重新使用
• Failed：失败，自动回收失败

5.2.实例：创建一个hostPath类型的PV

当你没有一个可靠的存储，但是数据又不能丢失，可以挂载到宿主机的路径，即使重启数据还在。

第一步：创建一个pv-host.yaml文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: host-pv-volume
  labels:
    type: local
spec:
  storageClassName: hostpath
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"  # 宿主机路径

第二步：执行yaml文件创建PV

[root@k8s-master01 ~]# kubectl create -f pv-host.yaml 
persistentvolume/host-pv-volume created
您在 /var/spool/mail/root 中有新邮件
[root@k8s-master01 ~]# kubectl get pv
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
host-pv-volume   1Gi        RWO            Retain           Available           hostpath                9s
pv-nfs           2Gi        RWO            Recycle          Available           nfs-slow                30m

6.PVC

6.1.Pod与PVC与PV的关系

由一张图说一下PV与PVC的绑定，Pod又是怎么挂载PVC

• 首先创建一个PV，它的名字是pv-nfs，storageClassName名字是nfs-slow（这个名字不唯一，就是说其他PV也可以叫这个名字）
• 然后创建一个PVC，它的名字是test-pv-claim，storageClassName名字是nfs-slow（PVC绑定PV也是根据这个名字判断，根据上一点说的特性也就是说一个PVC可以绑定多个storageClassName名字是nfs-slow的PV）注意PVC设置的资源大小要等于小于PV。
• 最后Pod使用的时候创建一个volumes，这个名字是test-pv-storage，这个volumes使用的PVC资源要写PVC的name，也就是test-pv-claim；等Pod中的容器挂载资源的时候挂载的名字是volumes的name，也就是test-pv-storage。

6.2.创建一个PVC挂载到Pod

注意：pvc要和Pod在同一个命名空间，而pv不需要；因为都是在默认空间，就没指定，需要注意。

第一步：编写一个PVC的yaml文件

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi  # 小于等于pv
  storageClassName: nfs-slow

第二步：执行yaml文件创建PVC；从下面这个状态来看已经绑定成功了，绑定了pv-nfs，类型为nfs-slow，都是前面指定的。

[root@k8s-master01 ~]# kubectl create -f pvc-nfs.yaml 
persistentvolumeclaim/test-pv-claim created
[root@k8s-master01 ~]# kubectl get pvc
NAME            STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pv-claim   Bound    pv-nfs   2Gi        RWO            nfs-slow       20s

第三步：创建Pod挂载PVC

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: dp-nginx
  name: dp-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dp-nginx
  strategy: {
    
    }
  template:
    metadata:
      labels:
        app: dp-nginx
    spec:
      volumes:
      - name: test-pv-storage
        persistentVolumeClaim:
          claimName: test-pv-claim
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: test-pv-storage

第四步：创建Pod，进入Pod查看挂载情况

[root@k8s-master01 ~]# kubectl replace -f dp-nginx.yaml 
deployment.apps/dp-nginx replaced
[root@k8s-master01 ~]# kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
dp-nginx-fcd88d6f8-prxcd   1/1     Running   0          22s
[root@k8s-master01 ~]# kubectl exec -ti dp-nginx-fcd88d6f8-prxcd -- bash
root@dp-nginx-fcd88d6f8-prxcd:/# df -Th
Filesystem              Type     Size  Used Avail Use% Mounted on
overlay                 overlay   17G  5.2G   12G  31% /
tmpfs                   tmpfs     64M     0   64M   0% /dev
tmpfs                   tmpfs    2.0G     0  2.0G   0% /sys/fs/cgroup
shm                     tmpfs     64M     0   64M   0% /dev/shm
/dev/mapper/centos-root xfs       17G  5.2G   12G  31% /etc/hosts
192.168.10.6:/data/k8s  nfs4      17G  2.4G   15G  14% /usr/share/nginx/html
tmpfs                   tmpfs    3.8G   12K  3.8G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                   tmpfs    2.0G     0  2.0G   0% /proc/acpi
tmpfs                   tmpfs    2.0G     0  2.0G   0% /proc/scsi
tmpfs                   tmpfs    2.0G     0  2.0G   0% /sys/firmware
# 可以看到10.6的共享目录已经挂载到了/nginx/html下

第五步：测试，在nfs服务器共享目录下创建资源，进入Pod容器内查看是否存在

# nfs服务器中创建资源
[root@localhost k8s]# ls
111.txt  hah
# 在Pod的nginx容器中查看
root@dp-nginx-fcd88d6f8-prxcd:/# cd /usr/share/nginx/html/
root@dp-nginx-fcd88d6f8-prxcd:/usr/share/nginx/html# ls
111.txt  hah
# 内容存在，说明创建成功