亲宝软件园·资讯

展开

云原生持久化存储PV与PVC

、重明 人气:0

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@k8s-master01 ~]# yum -y install nfs-utils

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

[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
# 内容存在,说明创建成功

加载全部内容

相关教程
猜你喜欢
用户评论