云原生技术持久化存储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@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 # 内容存在,说明创建成功
以上就是云原生技术持久化存储PV与PVC的详细内容,更多关于云原生持久化存储PV与PVC的资料请关注脚本之家其它相关文章!
相关文章
kubernetes需要默认的serviceaccount的原因解析
这篇文章主要介绍了kubernetes为何需要默认的serviceaccount,ServiceAccount 是 Kubernetes 中的一种重要概念,它的实际使用场景包括很多,本文给大家讲解的非常详细,需要的朋友可以参考下2023-04-04K8S部署Kafka界面管理工具(kafkamanager)方法详解
这篇文章主要介绍了K8S部署Kafka界面管理工具(kafkamanager)方法详解,需要的朋友可以参考下2022-01-01kubelet为cadvisor添加namespace/pod/container标签示例详解
这篇文章主要为大家介绍了kubelet为cadvisor添加namespace/pod/container标签示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪2023-09-09
最新评论