为什么要用volume？

首先。容器崩溃或重启时，所有的数据都会丢失，我们可以把数据保存到容器的外部，比如硬盘nfs，这样，即使容器没了，数据还在；第二就是容器之间是隔离的。我们如果想共享数据的话，就要使用volume，第三就是让容器能够使用外部的存储资源，比如公司的NAS存储、云硬盘

EmptyDir卷

EmptyDir，它是一个临时工作目录，Pod里的容器可以一起在上面放文件，交换数据，但是当pod被删除后，它就会被清空，它的生命周期跟pod是一致的，他提供给了应用一个临时缓存空间，比如下载临时文件，计算中间结果，他也让pod中的不同容器间实现了数据共享

HostPath卷

Host path，它是节点的本地存储，他将宿主机的文件挂载到pod中，但是要尽量少用，因为它会影响pod的可迁移性，Host path卷中的数据不会随着pod 删除而删除，因为它实实在在的存储在节点的磁盘中。比如运行kube-proxy 、CNI插件等系统守护进程的时候，需要访问/lib/models等主机目录，监控代理需要访问节点上的/proc或/sys文件系统来收集系统的指标。

PV/PVC

PV会为集群提供一块与pod和节点生命周期完全无关的持久化的网络存储，PV它由集群管理员预先配置，或者由storage class动态创建，它本身就是存储资源，比如一块nfs硬盘，PVC （persistent volume claim）是用户对存储的声明，用户在申领存储资源的时候需要声明，需要多大容量，需要什么访问模式，PVC会向系统申请合适的pv来绑定

工作原理就是：
管理员创建一批pv（或者配置一个storage class来实现动态供给）
用户在pod配置里定义一个PVC说明需要什么样的存储
K8s系统会为这个PVC找到一个匹配的pv，并与之绑定
用户在pod中通过引用PVC来挂载存储
pod删除后，PVC和PV依然存在，数据得以保留PV可以被回收，以备后续使用

Empty Dir的生命周期与pod同步，host path的生命周期与node同步，PV或PVC的生命周期是独立的

PV的访问方式

PV 的访问模式有四种：

- ReadWriteOnce：卷可以被一个节点以读写方式挂载。该访问模式也允许运行在同一节点上的多

个 Pod 访问卷。

- ReadOnlyMany：卷可以被多个节点以只读方式挂载。

- ReadWriteMany：卷可以被多个节点以读写方式挂载。

- ReadWriteOncePod：卷可以被单个 Pod 以读写方式挂载

PV的回收策略

K8s的PV主要支持三种回收策略，分别是retain delete和recycle 。

Return（保留）它的核心作用，是手动回收。当PVC被删除的时候，PV对象和其对应的外部存储资源以及其中的数据都会被保留下来，用户删除PVC时，与之绑定的PV不会被自动删除，它的状态会变成released在released状态下，这个PV不能再被新的PVC绑定。这时候我们可以将它挂载到某个pod上来查看其中的数据或者手动删除这个PV，但是这仅仅删除了k8s中的PV对象，外部的存储资源依然存在，所以我们还需要清理外部存储手动删除对应的外部存储卷才真正的释放空间，这适用于数据非常重要的场景，确保不会误删数据，是很多数据库生产环境中默认和推荐的策略，因为它提供了最高的数据安全性

第二种delete（删除）自动回收，当PVC被删除时，k8s会自动删除PV对象，并调用后端存储的接口释放并删除外部存储资源，这时候，存储空间被自动释放，数据会永久丢失。一般当存储缓存数据临时处理文件时，可以这样删除，及时释放存储资源，节省成本。

第三种是recycle，这种策略不安全且效率低，已经被取代，所以这里我们不做介绍。