数据卷（Volume）
Container 中的文件在磁盘上采用临时存储机制，这给给 Container 中运行的重要应用程序带来以下影响：
容器崩溃时文件丢失： kubelet 虽然会重新启动容器，但容器会以干净的状态重启，原有文件数据不可恢复。
多容器文件共享困难：在同一 Pod 中运行多个容器并需要共享文件时，临时存储无法提供稳定的的共享存储空间。
Kubernetes 卷（Volume）能够有效解决上述问题：
卷提供持久化存储：卷通过将容器文件挂载到持久化存储介质（如网络存储或本地磁盘），确保容器重启后数据仍然保留。
多容器共享相同的卷：同一 Pod 中的多个容器可挂载相同的卷，实现高效的文件共享与通信，避免数据复制和同步的开销。
数据卷（Volume）是 Pod 与外部存储设备之间的数据传输通道，同时也是 Pod 内部容器之间、Pod 之间以及 Pod 与外部环境实现数据共享的机制。
Kubernetes 支持多种类型的 Volume。通常，与 Kubernetes 代码一同发布和迭代的内置存储卷插件属于 In-Tree 类型；而由存储服务商基于 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：是集群中的一块存储空间，可由管理员预先配置或通过存储类（Storage Class）动态分配。作为集群级别的资源，PV 与节点类似，其生命周期独立于使用它的 Pod。PV 同样基于卷插件实现，但需注意：手动删除 PV 并不会自动清除后端存储资源。因此建议遵循“谁创建谁删除”原则：用户创建的 PV 应设置为保留回收策略并由创建者手动清理；动态创建的 PV 则由 CSI 驱动自动回收。
PVC：表示用户对存储资源的请求。其概念类似于 Pod：Pod 消耗节点资源，而 PVC 消耗 PV 资源。Pod 可申请特定量的 CPU 和内存，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 的需求和匹配规则自动将其与合适的 PV 绑定（或在创建 PVC 时直接指定 PV 名称）。应用程序即可通过 PVC 访问预分配的静态存储卷，获得持久化存储能力。
动态存储卷
Kubernetes 通过存储类（StorageClass）和存储插件提供动态存储卷功能。管理员基于可用存储资源和策略创建存储类模板，开发者在部署应用时通过 PVC 申请存储资源。存储插件根据存储类定义与后端存储池交互，动态创建符合需求的 PV 并绑定到 PVC。
动态存储卷的优势：
PV的自动化生命周期管理：通过 Provisioner 自动完成 PV 的创建和删除。
简化运维：通过自动创建PV，减少手动配置复杂度和管理员工作量。
容量优化：动态创建的 PV 容量与 PVC 需求精确匹配，实现存储容量规划最优。
子路径挂载支持：通过
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 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。 说明 并非所有持久卷类型都支持挂载选项。 |
