k8s的存储卷

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

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

容器在系统上的生命周期是短暂的，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