k8s的存储卷

发布时间:2024年01月10日

存储卷------数据卷

把容器内的目录,和宿主机的目录进行挂载。

容器在系统上的生命周期是短暂的,delete,k8s用控制(deployment)创建的pod,delete相当于重启,容器的状态也会回复到初始状态。

一旦回到初始状态,所有后天编辑的文件都会消失。

容器和节点之间创建一个可以持久化保存容器内文件的存储卷。即使容器被销毁,删除,重启,节点上的存储卷的数据依然存在,后续也可以继续使用。可以继续容器内目录和宿主机挂载,保存的数据继续使用。

1、emptyDir

作用:在容器内部共享存储卷,k8s系统中,是一个pod当中的多个容器共享一个存储卷目录。

emptyDir卷可以是pod当中容器在这个存储卷上读取和写入。

emptyDir是不能挂载到节点上的。随着pod的生命周期结束,emptyDir也会结束,数据也不会保留。

容器内部共享。lnmp。

第一个name,存储卷的名称,可以自定义,mountPath,定义容器内的挂载目录点,和节点或者其他容器的共享目录

- image:nginx:1.22

? name:nginx2

? volumeMounts:

? ? name:html

? ? mountPath:/data

引用上一个挂载点的名称,表示我将和/usr/share/nginx/html/这个目录挂载,由data目录和它挂载

command: ["/bin/bash","-c","while true";do]

volumes:

2、hostPath:

将容器内的挂载点,和节点上的目录进行挂载,hostPath可以实现数据的持久化。node节点被销毁,那么数据也会丢失。

污点设置为:NoExecute:节点上的pod会被驱逐,文件数据在不在?

pod的驱逐,并不是node节点被销毁,所有数据还保留在节点上。

pod被驱逐(基于控制器创建的)会在其他节点重新部署,又会在其他节点生成一个新的存储卷。数据依然可以持久化。

emptyDir的共享数据,会丢失。hostPath还在。

hostPath:

? path: /opt/test

? type:DirectoryCreate

一个pod有多个容器,用-c进入不同的容器

3、NFS共享存储:

/data/volumes? 192.168.233.0/24(rw,no_root) 9:38

方式1:

所有pod内的目录和节点上的nfs共享目录形成数据卷,所有的数据文件都保存在

释义图:

方式2:

9:52

指定server可以共享节点的ip地址,也可以是主机名,主机名要做映射

pvc和pv:

pv:全称Persistent Volume 持久化存储,描述和定义一个存储卷,pv是由我们运维人员来定的。

pvc:persistent Volume Claim 持久化存储的请求。pvc实际上是用来描述或者声明我希望使用什么样的pv来进行存储。

pvc-pv是一一对应的关系(描述,存储(大小))

pvc------>pv------NFS

pvc和pv都是虚拟化的概念,是k8s的抽象的虚拟的存储资源。

图示:

发起请求的读写方式要一致,读写空间要比它大,最优选择

pod内的挂载点声明一个请求,pvc请求,pvc会找一个最合适的pv来作为pod的存储卷,pv和共享目录再一一映射,最终由nfs来提供最终的共享存储空间。

pvc和pv之间的静态请求,一旦有成百个pvc怎么办,所以还有动态pvc。10:13

pv是集群当中的存储资源,pvc请求存储资源,也是对存储资源的一个检索(检查索引),选择一个最合适pv来存储资源。

pv和pvc之间是由生命周期管理:

1、Provisioning(配置)------pvc请求request------检索(找一个合适的pv)------pvc和pv(binding绑定)------使用------pod被删除------pv的releasing(释放)------recying(回收)

配置:静态,动态

绑定:就是把pv分配给pvc

使用:就是pod通过pvc使用存储资源------NFS

释放:pod解除和挂载卷volume的关系,删除pvc

回收:保留pv,以供下一个pvc使用。

pv的状态:

Available:可用,而且没有被任何pvc绑定

Bound:绑定,表示pv已经绑定到了pvc,绑定即使用

released:释放,pvc已经被删除了,但是pv的存储资源还没有被集群回收

Failed:表示pv资源回收失败,而且pv为不可用状态。

ReadWriteOnce:RWO,配置文件里面是全称,表示存储pv可读可写,但是只能被单个pod挂载

ReadOnlyMany:ROX,存储的pv可以以只读的方式被多个pod挂载

ReadRriteMany:RWX,存储可以支持读写的方式被多个pod共享。

nfs:可以支持三种读写和挂载的方式

SCSI

ISCSI:不支持ReadRriteMany

iscsiadm -m session -P 3

iscsiadm 查看服务器是否有iscsi设备

-m session:指定操作的会话模块,管理iscsi会话

-P 3:显示详细信息的级别。级别就是3.显示详细信息。

hostPath:只支持ReadWriteOnce方式。

集群回收pv资源的方式:

Retain 保留,pod和挂载点的数据不会被删除

Recycle:回收,pv上的数据被删除,挂载点的数据也被删除

Delete:淡出,解绑时,自动删除PV上的数据。(本地磁盘不能使用,AWS,EBS GCE)支持动态卷的可以使用,pv不再使用(云平台自己处理)。

补充:当pod运行之后,通过pvc请求到了pv,除非pod被销毁,否则无法删除pvc.

vim /etc/exports

/data/volumes 192.168.233.0/24(rw,no_root_squash)

/data/v1 192.168.233.0/24(rw,no_root_squash)

/data/v2?192.168.233.0/24(rw,no_root_squash)

/data/v3?192.168.233.0/24(rw,no_root_squash)

/data/v4?192.168.233.0/24(rw,no_root_squash)

/data/v5?192.168.233.0/24(rw,no_root_squash)

在各个节点上查看挂载情况

vim pv.yaml

一个yaml文件里面定义多个

apiversion: v1

kind: PersistentVolume

metadata:

? name: pv001

? labels:

? ? name: pv001

spec:

? nfs:

? ? path: /data/v1

? ? server: 192.168.233.94

? accseeModes: ["ReadwriteMany","ReadWriteOnce"]

? capacity:

? ? ? storage: 2Gi

---

apiversion:v1

kind: PersistentVolumeClaim

metadata:

? name:? mypvc

spec:

? accessModes: ["ReadWriteMany"]

#pvc期望请求的pv的读写挂载类型是什么

? resource:

? ? requests:

? ? ? storage: 2Gi

#pvc期望请求pv的存储大小是2G,期望的pv类型:readwritemany 大小是2G

---

11:24

静态

pvc--------

delete之后

动态卷是要删除的。

总结:

k8s当中存储卷的模式:

emptyDir:容器内存储卷,随着pod被销毁,也会销毁,数据不保留

hostPath:节点目录的存储卷,可以实现持久化存储。数据在每个节点上都有,不方便集中管理

nfs:共享目录存储卷,可以实现持久化,数据集中在一个目录,方便管理

pv和pvc:

pvc请求---------pv的存储资源------磁盘空间(NFS)

nfs支持pvc的所有挂载方式和读写模式

hostPath仅支持ReadWriteOnce方式

pvc是以检索的方式找到匹配的pv资源

检索挂载方式和读写方式

检索pv能够提供的存储资源的大小

谁合适选谁

保留:默认可以不写

回收:自动回收,节点上的数据会被删除

删除:pv会变成failed模式,不可用,数据也会被删除。

静态比较繁琐,如何能自动的匹配pv资源呢?

动态pvc

文章来源:https://blog.csdn.net/m0_70766460/article/details/135494120
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。