容器内的目录和宿主机的目录进行挂载
容器在系统上的生命周期是短暂的,一旦容器被删除,数据会丢失。k8s基于控制器创建的pod,delete相当于重启,容器的状态会恢复到原始状态。一旦回到原始状态,后天编辑的文件都会消失,所以容器和节点之间要创建一个持久化保存容器内文件的存储卷,即使容器被销毁、删除、重启,节点上的存储卷依然存在,后续可以继续将容器内的目录和宿主机挂载,保存的数据可以继续使用
(1)emptyDir:容器内部共享存储卷,在k8s系统中是一个pod中的多个容器共享一个存储卷目录。emptyDir可以使pod中的容器在这个存储卷上读取和写入,但不能挂载到节点上,随着pod的生命周期结束,emptyDir也会被销毁,导致数据丢失
一个pod里两个容器。加上-c 容器名进入一个pod里的不同容器
(2)hostPath:将容器内的目录和节点上的目录进行挂载,hostPath可以实现数据持久化。若node节点被销毁,数据也会丢失(常用)
注意:这种挂载方式非常直接,但有一个重要的限制:hostPath?是特定于节点的,而不是集群范围的
污点设置为NoExecute会把节点上的pod驱逐,文件数据在不在?【面试题】
emptyDir的共享数据会丢失
hostPath的共享数据不会丢失。pod被驱逐,不是node节点被销毁,之前的数据还保留在原来的节点上;基于控制器创建的pod被驱逐会在其他节点重新部署,所以会在其他节点生成一个新的存储卷,数据依然可以持久化
nfs的共享数据不会丢失
容器 | 容器内的目录 | 挂载点 |
容器1 | /usr/share/nginx/html | 节点上的/opt/test |
容器2 | /data | 节点上的/opt/test |
因为两个容器内的目录均和节点上的/opt/test进行挂载,所以这个两个容器之间的目录也能数据同步,形成容器1的/usr/share/nginx/html、容器2的/data、节点上的/opt/test三者数据同步 |
注意:这种挂载方式非常直接,但有一个重要的限制:hostPath?是特定于节点的,而不是集群范围的
hostPath?是特定于节点的,而不是集群范围的
查看一个pod里多个容器的日志。-c 容器名
(3)NFS共享存储:数据集中在同一个节点上管理(常用。推荐)
所有pod内的目录都和节点上的NFS共享目录形成数据卷,所有数据文件都保存在共享目录中,集中、方便管理
指定共享目录/data/volumes
发布共享目录
在其他节点查看共享目录
方式1:指定IP地址
测试
查看容器中是否同步数据
结论:每个pod中数据同步
结论:每个pod中的所有容器数据同步
方式2:指定主机名
所有主机做主机名映射
测试
在共享目录中创建文件
查看pod是否同步数据
结论:容器和节点上的挂载目录数据同步
k8s持久化存储数据方式的特点 | ||
方式 | 挂载点 | 特点 |
emptyDir | 容器与容器进行挂载 | 一旦pod被销毁,数据丢失 |
hostPath | 容器与节点进行挂载 | 持久化存储数据,pod销毁数据仍存在,但数据分散存储在各个节点上,不方便管理 |
nfs | 容器与节点进行挂载 | pod销毁数据仍然存在,并且数据集中在一个节点上,方便管理 |
全称Persistent Volume Claim持久化存储的请求,描述或声明希望使用什么样的pv来进行存储。pvc是虚拟化的请求存储资源或检索存储资源,选择一个最合适的pv来存储资源
全称Persistent Volume持久化存储卷,描述和定义一个存储卷,pv由运维人员来定的。pv是集群中虚拟化的存储资源
pv和pvc是一一映射的关系(描述、存储大小)
pvc向pv请求,存储在NFS服务器上
pv和pvc都是虚拟化的概念,是k8s的抽象的虚拟的存储资源
pv3和pv4都满足要求,但优先选择pv3,若pv3被占用,则选择pv4
配置provisioning→pvc请求request→检索(找一个合适的pv)→pvc和pv绑定bending→使用use→pod被删除,pv的资源被释放releasing→回收recycling
配置分为静态请求和动态请求
绑定:把pv分配给pvc
使用:pod通过pvc使用存储资源
释放:pod解除和挂载卷之间的关系,删除pvc
回收:保留pv以供下一个pvc使用
①静态请求
②动态请求
Available | 可用,且没有被任何pvc绑定 |
Bound | 绑定,pv已经绑定pvc,绑定即使用 |
released | 释放,pvc已被删除,但集群尚未回收pv的存储资源 |
Failed | pv资源回收失败,且pv处于不可用状态 |
ReadWriteOnce | RWO,存储pv可读可写,但只能被单个pod挂载 pv可读可写,只能挂载单个pod |
ReadOnlyMany | ROX,存储pv可以以只读的方式被多个pod挂载 pv只读,能挂载多个pod |
ReadWriteMany | RWX,存储pv可以以读写的方式被多个pod挂载 pv可读可写,能挂载多个pod |
NFS支持以上三种读写和挂载方式,hostPath只支持ReadWriteOnce方式(在配置文件中都是全称) | |
ISCSI设备不支持ReadWriteMany方式(注意环境检查) iscsiadm -m session -P 3?#查看服务器是否有iscsi设备 -m session指定操作的会话模块,管理iscsi的会话 -P 3显示详细信息的级别(3表示显示详细信息) |
Retain | 保留。pod和挂载点的数据不会被删除(默认策略。常用) 回收资源后,pv处于released状态,需人工调整成Available状态 |
Recycle | 回收。pv上的数据会被删除,挂载点的数据也被删除 回收资源后,pv自动调整成Available状态 |
Delete | 删除。解绑时自动删除pv上的数据(本地硬盘不能使用,只有云平台支持动态卷的可以使用),pv不再可用,云平台自己处理 |
当pod运行之后通过pvc请求到了pv,除非pod被销毁,否则无法删除pvc(先删除pod才能删除pvc)
运维负责pv,创建好持久化存储卷,声明好读写和挂载类型,以及可以提供的存储空间。开发负责pvc,与开发对接好条件:期望的读写和挂载类型以及存储空间
1、发布共享目录
在其他节点上查看共享目录
(一)保留策略Retain(pod销毁,存储卷上的数据不会被删除)
2、创建多个pv
定义pv能支持的读写方式和能接收pvc请求的存储大小
此时各个pv支持的读写方式、存储大小以及与节点的挂载目录:
PV | 支持的读写方式 | 存储大小 | 节点上的挂载目录 |
PV001 | ReadWriteMany ReadWriteOnce | 1G | /data/v1 |
PV002 | ReadWriteOnce | 2G | /data/v2 |
PV003 | ReadWriteMany ReadWriteOnce | 2G | /data/v3 |
PV004 | ReadWriteMany ReadWriteOnce | 4G | /data/v4 |
PV005 | ReadWriteMany ReadWriteOnce ReadOnlyMany | 5G | /data/v5 |
客户端发送PVC请求到PV上请求存储资源,PV通过nfs方式挂载到节点上的目录,实际上数据还是存储在节点上 |
3、定义pvc
向pv发起请求
4、测试
pvc请求具体用哪个pv的存储,pv和物理存储做挂载,最终由物理设备提供持久化存储
5、删除pvc(运行中的pod无法删除pvc)
??先删除pod
??再删除pvc
6、pv恢复可用状态
(二)回收策略Recycle
2、定义pv
3、定义pvc
向pv发起请求
4、测试
在共享目录中创建文件
查看容器是否同步数据
结论:数据同步
5、删除pvc
稍等一会自动变成可用状态
(三)删除策略delete
2、定义pv
3、定义pvc
向pv发起请求
4、测试
在共享目录中创建文件
查看容器中是否数据同步
结论:数据同步成功
5、删除pvc
Failed表示资源回收失败,并且pv处于不可用状态
注:delete只支持动态卷删除
6、恢复pv