数据卷（Volume）
Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用程序带来以下问题：
当容器崩溃时文件丢失：虽然 kubelet 会重新启动容器，但容器会以干净的状态重启；
在同一 Pod 中运行多个容器并需要共享文件。
Kubernetes 卷（Volume） 这一抽象概念能够解决以上问题：
卷提供持久化存储的机制，可以将容器中的文件存储到持久化存储介质（如网络存储、本地存储等）上。当容器重新启动时，可以重新挂载卷，使文件内容保持不变，确保数据的持久性和可靠性；
多个容器可以访问相同的卷，从而实现容器之间的文件共享和通信。这对于需要共享数据的场景避免了复制和同步数据的开销。
数据卷（Volume）作为Pod与外部存储设备进行数据传递的通道，也是Pod内部容器间、Pod与Pod间、Pod与外部环境进行数据共享的方式。
Kubernetes提供了非常丰富的Volume类型，通常，Kubernetes内置提供的存储卷插件可归类为In-Tree类型，它们同Kubernetes源代码一同发布和迭代，而由存储服务商借助于CSI或FlexVolume接口扩展的独立于Kubernetes代码的存储卷插件则统称为Out-Of-Tree类型，目前CSI是较为推荐的扩展接口。
数据卷使用原则
一个Pod可以挂载多个Volume。
一个Pod可以挂载多种类型的Volume。
每个被Pod挂载的Volume卷，可以在不同的容器间共享。
Kubernetes环境推荐使用PVC和PV方式挂载Volume。
虽然单Pod可以挂载多个Volume，但是并不建议给一个Pod挂载过多数据卷。
说明
数据卷（Volume）生命周期和Pod一致，即Pod被删除的时候，数据卷（Volume）也一起被删除（Volume中的数据是否丢失取决于Volume的具体类型）。
PV和PVC
Kubernetes引入了PV（PersistentVolume）和PVC（PersistentVolumeClaim）两个资源对象，用于定义、管理存储。它们提供了抽象层，使得应用程序可以声明其对存储的需求，而无需关心具体基础设施。
| 名称 | 说明 |
|---|---|
| PV | 持久卷（PersistentVolume），是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群级别资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 |
| PVC | 持久卷声明（PersistentVolumeClaim）， 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 。 |
以下是对PV及PVC典型字段说明：
| PV/PVC | 字段名称 | 字段说明 |
|---|---|---|
PV
| 访问模式 | 定义 PV 的访问模式，包括：
|
| 回收策略 | PV对象的回收策略表示当PVC释放时如何处理该数据卷。 回收策略包括：
| |
| 容量 | 定义 PV 的容量大小。 | |
| 卷模式 | Kubernetes 支持两种卷模式：
| |
| 挂载选项 | 可以指定持久卷被挂载到节点上时使用的附加挂载选项。Kubernetes 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。 说明： 并非所有持久卷类型都支持挂载选项。 | |
| 标签 | 标签（labels）是用于对 PV 对象进行标记和分类的元数据属性，可以赋予 PV 以自定义的属性或标识。 | |
| PVC | 访问模式 | PVC（PersistentVolumeClaim）可以指定对持久化存储的访问模式需求； 在绑定 PV 时，系统将尝试找到访问模式满足 PVC 需求的PV，否则PVC 将无法绑定到 PV。 |
| 卷模式 | Kubernetes 支持两种卷模式：
| |
| 容量 | 表示PVC指定的容量。 说明： 当 PVC 与 已有PV 绑定时，PV 的容量必须大于或等于 PVC 所需的容量。否则，PV 将无法满足 PVC 的需求，绑定将失败。 | |
| 存储类 | 可以通过为 storageClassName 属性设置 storageClass 的名称来请求特定的存储类。 只有所请求的类的 PV 卷，即 storageClassName 值与 PVC 设置相同的 PV 卷， 才能绑定到 PVC 申领。 |
存储卷挂载
容器存储数据卷挂载有以下方式：静态存储卷、动态存储卷。
静态存储卷
静态存储卷是由集群管理员预先创建的 PV（PersistentVolume）。管理员会根据集群中的存储需求，提前分配一些存储介质（如云盘、文件系统等），并创建相应的 PV 对象。这些 PV 对象处于可用状态，等待 PVC（PersistentVolumeClaim）来使用和绑定。
当应用程序需要使用存储服务时，可以通过定义 PVC 来申请所需的存储资源。Kubernetes 将根据 PVC 的需求和相关的匹配规则，自动将 PVC 与合适的 PV 进行绑定（或者创建PVC时可以指定PV名称）。这样，应用程序就可以通过 PVC 访问到预先创建的静态存储卷，获得持久化的存储能力。
动态存储卷
Kubernetes使用存储类（StorageClass），通过存储插件提供动态存储卷能力。
一般管理员根据集群中可用的存储资源和策略，创建存储类模板。应用开发者在部署应用程序时，通过定义 PVC 来申请所需的存储资源。存储插件会根据存储类的定义与后端存储池交互，创建一个符合需求的 PV，并将其绑定到 PVC 上。
动态存储卷的优势：
动态存储卷让Kubernetes实现了PV的自动化生命周期管理，PV的创建、删除都通过Provisioner完成。
自动化创建PV对象，减少了配置复杂度和系统管理员的工作量。
动态卷可以实现PVC对存储的需求容量和Provisioner出来的PV容量一致，实现存储容量规划最优。
挂在SubPath卷：Kubernetes提供了volumeMounts.subPath属性配置，可用于指定所引用的卷内的子路径，而不是其根路径。
存储类（StorageClass ）说明如下：
| 存储驱动（provisioner） | 用来决定使用哪个卷插件制备 PV。 |
| 回收策略(reclaimPolicy) | 由 StorageClass 动态创建的 PV会在类的 reclaimPolicy 字段中指定回收策略，可以是 Delete 或者 Retain。如果 StorageClass 对象被创建时没有指定 reclaimPolicy，默认为 Delete。 通过 StorageClass 手动创建并管理的 PV会使用它们被创建时指定的回收策略。 |
| 绑定模式（volumeBindingMode） | 该控制了卷绑定和动态供应应该发生在什么阶段。 Immediate 模式：表示一旦创建了 PVC，也就完成了卷绑定和动态供应。 对于由于拓扑限制而非集群所有节点可达的存储后端，PV会在不知道 Pod 调度要求的情况下绑定或者制备。 WaitForFirstConsumer模式： 该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。 PV会根据 Pod 调度约束指定的拓扑来选择或供应。 说明 volumeBindingMode配置为WaitForFirstConsumer，可以解决以下可能情况： 1、创建了A可用区的数据卷，但是A可用区的节点资源已经耗光，导致Pod启动无法完成挂载。 2、集群管理员在规划PVC、PV的时候不能确定在哪些可用区创建多个PV来备用。 |
| 卷扩展 | 当StorageClass 的 allowVolumeExpansion 字段设置为 true ，表示动态创建的PV可以配置为可扩展，即允许用户通过编辑相应的 PVC 对象来调整卷大小。 |
| 挂载选项 | 由 StorageClass 动态创建的 PV 将使用类中 mountOptions 字段指定的挂载选项。 Kubernetes 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。 说明 并非所有持久卷类型都支持挂载选项。 |
