k8s 存储卷和pvc,pv

存储卷---数据卷

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

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

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

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

1,emptyDir

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

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

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

kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-r un=client -o yaml > test1.yaml

k8s 存储卷和pvc,pv_第1张图片

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

#引用.上一个挂载的名称,表示我将和/us r/share/nginx/html/这个目录挂载,由data目录和他挂载

进入容器,指定容器 -c 指定

kubectl exec -it nginx-74d46b66bd-747x2 -c nginx1 bash

k8s 存储卷和pvc,pv_第2张图片

k8s 存储卷和pvc,pv_第3张图片

只能用于容器内部共享文件

例如:lnmp中

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

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

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

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

emptyDir如果被驱逐,共享数据会丢失。

k8s 存储卷和pvc,pv_第4张图片

k8s 存储卷和pvc,pv_第5张图片

k8s 存储卷和pvc,pv_第6张图片

将pod删除之后,节点上的数据还在

k8s 存储卷和pvc,pv_第7张图片

3,NFS共享存储:

在k8s4上做创建一个volumes

查看暴露出来的共享目录

k8s 存储卷和pvc,pv_第8张图片

在其他机器上查看

nfs两种方式

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

k8s 存储卷和pvc,pv_第9张图片

k8s 存储卷和pvc,pv_第10张图片

k8s 存储卷和pvc,pv_第11张图片

k8s 存储卷和pvc,pv_第12张图片

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

2,用域名一定要做主机映射

k8s 存储卷和pvc,pv_第13张图片

kubectl delete -f test1.yaml

可以基于yaml文件删除pod,yaml文件还在

工作中最常见的存储卷的方式是hostPath,NFS

推荐nfs

pvc和pv

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

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

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

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

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

k8s 存储卷和pvc,pv_第14张图片

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

匹配最优的pv3,只有pv3被占用了,才会选择pv4

pvc和pv 有两种请求方式,静态请求和动态请求

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

pv是集群当中的存储资源,pvc请求存储资源,也是对存储资源的一个检索(检查索引)选择一个最合适的pv来存储资源。篇v和pvc之间是有生命周期管理:

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

配置:静态,动态

绑定:就是把pv分配给pvc

使用:就是pod提供pvc使用存储资源

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

回收:保留pv,让下一个pvc使用

pv的状态:

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

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

released:释放,pvc已经被删除了,但是pv的存储资源还没有被集群回收Failed:表示pv资源回收失败,而且pv为不可用状态。

支持的读写方式:

ReadWriteOnce RWO,配置文件里是全称,存储pv可读可写,但是只能被当pod挂载。

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

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

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

hostPath:只支持ReadWriteOnce 方式

SCSI

ISCS不支持ReadWriteMany

lsscsi

iscsiadm -m session -P 3

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

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

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

hostPath:支持ReadWriteOnce 方式。

在生产中要检查

集群回收pv资源的方式:

Retain 保留,pod和挂载点的数据不会被删除(默认即可)

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

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

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

暴露多个nfs共享文件

k8s 存储卷和pvc,pv_第15张图片

k8s 存储卷和pvc,pv_第16张图片

在其他节点查看

k8s 存储卷和pvc,pv_第17张图片

编辑pv文件

vim pv.yaml

k8s 存储卷和pvc,pv_第18张图片

k8s 存储卷和pvc,pv_第19张图片

编写pvc文件

vim pvc.yaml

k8s 存储卷和pvc,pv_第20张图片

根据需求精确匹配

kubectl apply -f pvc.yaml

pvc----请求用哪个pv的存储----pv和物理存储做映射(挂载)----物理设备提供存储卷

删除pvc,要先删除pod

k8s 存储卷和pvc,pv_第21张图片

表示回收完毕

恢复pv到可用状态:

删除红框内的部分

kubectl edit pv pv003

k8s 存储卷和pvc,pv_第22张图片

设定回收策略:

将pv003和pv004更改回收策略Recycle

k8s 存储卷和pvc,pv_第23张图片

k8s 存储卷和pvc,pv_第24张图片

k8s 存储卷和pvc,pv_第25张图片

回收完之后,资源会被删除

删除pvc之后

Delete策略,只支持动态卷

k8s 存储卷和pvc,pv_第26张图片

k8s 存储卷和pvc,pv_第27张图片

返回原状态

kubectl edit pv pv003

k8s 存储卷和pvc,pv_第28张图片

总结:

k8s当中存储卷的模式:

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

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

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

pv和pvc

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

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

hostPath仅支持支持ReadWriteOnce方式。

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

检索挂载方式和读写模式

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

谁合适选谁

保留:默认可以不写.

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

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

k8s 存储卷和pvc,pv_第29张图片

静态比较麻烦,自动的匹配pv资源呢?动态pvc

在工作当中静态pv和pvc

运维负责:创建好持久化存储卷,声明好读写和挂载类型 以及可用提供的存储空间

pvc开发做,要和开发沟通好,你期望的读写和挂载类型,以及存储空间。

动态pv

当我发布pvc之后可用生成pv,还可用在共享服务器上之间生成挂载目录。

pvc从直接绑定和使用pv

动态pv需要两个组件:

1,卷插件,k8s本身支持的动态篇v插件不包括nfs,需要声明和安装一个外部插件

Provisioner:存储分配器。动态创建pv,任何根据pvc的请求自动绑定和使用。

2,StorageClass:来定义pv的属性,存储类型,大小,回收策略。

还是用nfs来实现动态PV,NFS支持的方式NFS-client,Provisioner来适配nfs-client nfs-client-provisioner卷插件。

k8s 存储卷和pvc,pv_第30张图片

实验

先插件一个共享目录

mkdir k8s

chmod 777 k8s

vim /etc/exports

/opt/k8s 192.168.176.0/24(rw,no_root_squash,sync)

systemctl restart rpcbind

systemctl restart nfs

showmount -e

在其他节点查看

先创建一个serviceAccountl

NFS PRovisioner:是一个插件,没有权限是无法再集群当中获取k8s的消息。插件要有权限能够监听apiserver,获取get,list(获取集群的类别资源)create delete

vim nfs-client-rbac.yaml

k8s 存储卷和pvc,pv_第31张图片

rbac:Rple-based ACCESS CONTROL

定义角色在集群当中可以使用的权限

-apiGroups: [""]

#apigroups定义了规则使用哪个API的组,空字符"",代表直接使用API的核心组的资源。

verbs: ["get","list","watch","create","delete"]

#表示权限的动作

kubectl apply -f nfs-client-rbac.yaml

角色 权限都已经创建完毕

部署插件:NFS -privisioner。deplpyment来创建插件 pod

1.20 之后有一个新的机制

selfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连接,self-link是一个唯一标识符号,可以用于标识k8s集群当中每个资源的对象。

self link是值是一个URL,指向改资源对象的k8s api的路径。

更好的实现资源对象的查找和引用。

vim /etc/kubernetes/manifests/kube-apiserver.yaml

k8s 存储卷和pvc,pv_第32张图片

feature-gates=RemoveSelfLink=false

feature-gates:在不破坏现有规则以及功能基础_上引入新功能或者修改现有功能的机制。禁用不影响之前的规则。

部署nfs-provisioner的插件:

nfs的provisioner的客户端已pod的方式运行在集群当中,监听k8s集群当中pv的请求。动态的创建于nfs服务器相关的pv。

容器里使用的配置,在provisioner当中定义好环境变量,传给容器。storageclasss的名称,nfs服务器的地址,nfs的目录。

vim nfs-client-provisioner.yaml

k8s 存储卷和pvc,pv_第33张图片

provisioner要创建pv,在共享目录里创建的

创建 StorageClass,负责建立 PVC 并调用 NFS provisioner 进行预定的工作,并让 PV 与 PVC 建立关联

vim nfs-client-storageclass.yaml

k8s 存储卷和pvc,pv_第34张图片

kubectl apply -f nfs-client-storageclass.yaml

kubectl get storageclasses.storage.k8s.io

NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE

nfs-client-storageclass nfs-storage Retain Immediate true 106s

NAME: StorageClass 的名称,这里是 nfs-client-storageclass。

PROVISIONER: Provisioner 的名称,这里是 nfs-storage。它指定了用于动态创建 PV 的 Provisioner。

RECLAIMPOLICY: 回收策略,这里是 Delete。表示当 PersistentVolume(PV)被释放时,它的数据将被删除。

其他可能的值包括 Retain,表示在释放 PV 时保留数据。

VOLUMEBINDINGMODE: 卷绑定模式,这里是 Immediate。表示当 PVC 请求创建 PV 时,

系统会立即绑定一个可用的 PV。另一种可能的值是 WaitForFirstConsumer,

表示系统将等待第一个使用者出现后再绑定 PV。

ALLOWVOLUMEEXPANSION: 允许卷扩展,这里是 false。表示不允许扩展 PV 的容量。

如果设置为 true,则表示允许在运行时扩展 PV 的容量。

创建 PVC 和 Pod 测试

vim test-pvc-pod.yaml

k8s 存储卷和pvc,pv_第35张图片

k8s 存储卷和pvc,pv_第36张图片

总结:动态pv

provisioner插件---支持nfs

stroagclass:定义pv的属性

动态pv的默认策略是删除(面试题)

动态pv删除之后的状态,released。

1,插件账号,给卷插件能够在内部通信,获取资源,监听事件,插件,删除,更新pv

2,插件卷插件pod,卷插件的pod插件pv

3,storageclass:给pv赋予属性(pvc删除之后pv的状态,以及回收策略)

4,插件pvc----完成。

你可能感兴趣的:(kubernetes,docker,容器)