存储卷（数据卷）—主要是nfs方式挂载

1、定义

容器在系统上的生命周期是短暂的，一旦容器被删除，数据会丢失。k8s基于控制器创建的pod，delete相当于重启，容器的状态会恢复到原始状态。一旦回到原始状态，后天编辑的文件都会消失，所以容器和节点之间要创建一个持久化保存容器内文件的存储卷，即使容器被销毁、删除、重启，节点上的存储卷依然存在，后续可以继续将容器内的目录和宿主机挂载，保存的数据可以继续使用

2、存储方式

（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销毁数据仍然存在，并且数据集中在一个节点上，方便管理

3、PV和PVC【面试必问】

（1）pvc定义

全称Persistent Volume Claim持久化存储的请求，描述或声明希望使用什么样的pv来进行存储。pvc是虚拟化的请求存储资源或检索存储资源，选择一个最合适的pv来存储资源

（2）pv定义

全称Persistent Volume持久化存储卷，描述和定义一个存储卷，pv由运维人员来定的。pv是集群中虚拟化的存储资源

pv和pvc是一一映射的关系（描述、存储大小）

pvc向pv请求，存储在NFS服务器上

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

pv3和pv4都满足要求，但优先选择pv3，若pv3被占用，则选择pv4

（3）pv和pvc之间有生命周期管理

配置provisioning→pvc请求request→检索（找一个合适的pv）→pvc和pv绑定bending→使用use→pod被删除，pv的资源被释放releasing→回收recycling

配置分为静态请求和动态请求

绑定：把pv分配给pvc

使用：pod通过pvc使用存储资源

释放：pod解除和挂载卷之间的关系，删除pvc

回收：保留pv以供下一个pvc使用

（4）pv和pvc的映射方式

①静态请求

②动态请求

（5）pv的状态

Available	可用，且没有被任何pvc绑定
Bound	绑定，pv已经绑定pvc，绑定即使用
released	释放，pvc已被删除，但集群尚未回收pv的存储资源
Failed	pv资源回收失败，且pv处于不可用状态

（6）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表示显示详细信息）

（7）集群回收pv资源的方式

Retain

保留。pod和挂载点的数据不会被删除（默认策略。常用）

回收资源后，pv处于released状态，需人工调整成Available状态

Recycle

回收。pv上的数据会被删除，挂载点的数据也被删除

回收资源后，pv自动调整成Available状态

Delete

删除。解绑时自动删除pv上的数据（本地硬盘不能使用，只有云平台支持动态卷的可以使用），pv不再可用，云平台自己处理

当pod运行之后通过pvc请求到了pv，除非pod被销毁，否则无法删除pvc（先删除pod才能删除pvc）

运维负责pv，创建好持久化存储卷，声明好读写和挂载类型，以及可以提供的存储空间。开发负责pvc，与开发对接好条件：期望的读写和挂载类型以及存储空间

创建静态pv实验（默认策略是Retain）

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方式挂载到节点上的目录，实际上数据还是存储在节点上