本文详细介绍 Kubernetes 存储相关的常见概念，涵盖访问模式、绑定模式、回收策略等关键概念，帮助您在使用存储前，提前了解存储的基本知识。 ## Volume（存储卷） ### 存储卷概述在 Kubenetes 集群中，容器内文件在磁盘上是临时存放的，这会给关键业务应用带来以下问题： * 容器崩溃或重建时，内部文件会随之丢失，无法实现数据持久化。 * 同一 Pod 内多容器协同运行时，无法便捷、安全地实现文件共享与数据交换。为解决上述问题，Kubernetes 抽象出 Volume（存储卷）资源。存储卷隶属于 Pod，并非独立可创建的资源对象，必须在 Pod 规格中定义并声明。Pod 内所有容器均可使用存储卷，但需通过挂载方式将存储卷关联至容器内指定目录。 ### 存储卷使用基本原则 * 一个 Pod 可同时挂载多个存储卷，但为保证稳定性与可维护性，不建议在单个 Pod 中挂载过多存储卷。 * 一个 Pod 支持同时挂载不同类型的存储卷，以适配多样化的数据存储需求。 * Pod 内挂载的存储卷可在多个容器间共享，实现容器间数据互通。 * 在 Kubernetes 生产环境中，推荐使用 PVC / PV 体系进行存储卷的挂载与管理。 :::tip 存储卷的更多介绍，请参见 [官方文档](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/)。 ::: ## 存储卷访问模式存储卷访问模式（accessModes）是 Kubernetes 用于描述存储卷能被集群节点如何挂载使用的标准约束，用于定义存储卷的并发访问能力与权限范围。 Kubernetes 定义了三种官方标准访问模式，所有兼容 CSI 的存储服务均遵循该规范： * ReadWriteOnce：简写为 RWO，即单节点读写。表示存储卷同一时间只能被单个集群节点以读写方式挂载。 * ReadOnlyMany：简写为 ROX，即多节点只读。表示存储卷可被集群内多个节点同时以只读方式挂载。 * ReadWriteMany：简写为 RWX，即多节点读写。表示存储卷可被集群内多个节点同时以读写方式挂载。不同类型存储卷支持的访问模式，如下表所示。 |存储类型 |ReadWriteOnce |ReadWriteMany | |---|---|---| |弹性块存储（EBS） |✅ |❌ | |对象存储（TOS） |❌ |✅ | |文件存储（NAS） |❌ |✅ | |弹性文件存储（EFS） |❌ |✅ | |文件存储（vePFS） |❌ |✅ | |大数据文件存储（CloudFS） |❌ |✅ | ## 存储卷绑定模式存储卷绑定模式（volumeBindingMode）是 StorageClass 的核心配置项，用于控制 PVC 何时与 PV 绑定、以及动态 PV 何时创建 Kubernetes。它决定了存储资源的分配时机，直接影响 Pod 调度成功率与多可用区（多 AZ）场景的稳定性。Kubernetes 支持两种绑定模式，即 Immediate 和 WaitForFirstConsumer，未显式配置时默认使用 Immediate。 ### Immediate 绑定模式立即绑定模式，当用户创建 PVC 时，会在集群寻找符合要求的 PV 进行绑定，如果没有找到符合要求的 PV ，则会开启自动创建流程： 1. 如果新创建的 PVC 定义了存储类名称，那么存储类对应的 Provisioner 插件将开始自动创建 PV。 2. Provisioner 根据 PVC 定义的参数以及存储类定义的参数创建 PV。 3. Provisioner 在存储资源池创建数据卷，完成后会结合数据卷信息创建 PV。 4. PV 创建完成后完成与 PVC 的绑定。总的来说，如果存储类中定义以 Immediate 绑定模式完成 PV 和 PVC 的绑定，那么当 PVC 创建时会立即绑定现有的合适 PV，若没有合适的，则立即新建一个合适的 PV 以供绑定。 ### WaitForFirstConsumer 绑定模式延迟绑定模式，当用户创建 PVC 时，不会立即执行绑定 PV 的动作，而是等待这个 PVC 被 Pod 消费，绑定的流程如下： 1. 当 Pod 创建并消费到这个PVC 时，系统发现此 PVC 采用的是延迟绑定。 2. 调度器继续完成调度功能，并把调度结果同步到 PVC 的 metadata 中。 3. Provisioner 发现 PVC 中写入了调度信息，根据调度信息判断目标存储的相关信息。例如：节点、可用区等。 4. 触发 PV 的创建过程。 :::tip 云盘在挂载时，存在可用区的限制，只有可用区一致的的云盘和节点才能挂载在一起，这种限制可能导致使用时存在以下问题。 * 在 A 可用区创建了云盘，但是发现 A 可用区的节点资源不足，Pod 在 B 可用区的节点启动无法挂载。 * 当存在多可用区资源时，难以事先评估规划各个可用区合理的 PV 数量。 ::: 当存在多个可用区时，可以采用 WaitForFirstConsumer 绑定模式可以规避以上问题。当用户创建 PVC 时，Provisioner 将不再立即进行 PV 的绑定或新建，而是会等待这个 PVC 被 Pod 消费时才会执行创建过程。在此模式下，在 Pod 启动时，先进行 Pod 的调度，当确认 Pod 的运行位置后，再根据 Pod 所在可用区信息进行 PV 和云盘的创建，从而保障云盘 Pod 运行节点在相同可用区。所以，在具备多个可用区的集群环境下，更加推荐使用 WaitForFirstConsumer 绑定模式。 ### 绑定模式对比不同绑定模式的对比，如下表所示。 |对比项 |**Immediate（立即绑定）** |**WaitForFirstConsumer（延迟绑定）** | |---|---|---| |绑定时机 |PVC 创建时立即执行 |第一个使用 PVC 的 Pod 调度时执行 | |拓扑感知 |无（忽略 Pod 调度约束） |有（完全匹配 Pod 节点 / 可用区） | |多可用区适配 | 差（易调度失败） |极佳（生产推荐） | |Pod 启动速度 |快（存储卷已就绪） |稍慢（调度时才创建存储卷） | |资源利用率 |可能浪费（提前分配） |高（按需分配） | ## 存储卷回收策略回收策略（persistentVolumeReclaimPolicy）是 PersistentVolume/StorageClass 的核心配置项，用于控制当绑定该 PV 的 PVC 被删除后，存储卷与数据如何处理，是持久化存储生命周期管理的关键配置。支持 Delete（删除策略）、Retain（保留策略）两种回收策略。 |对比项 |Delete（删除策略） |Retain（保留策略） | |---|---|---| |行为 |当 PVC 被删除时，PV 与底层存储卷同时自动删除，数据一并清除。 |当 PVC 被删除后，PV 与底层存储资源均不会被删除，需要手动删除回收。PVC 删除后 PV 资源状态为`Released`，且不能直接再次被 PVC 绑定使用。 | |特点 |自动化程度高，资源自动释放。但删除后数据不可恢复。 |数据安全，不会误删；需要管理员手动清理 PV 和底层存储。 | |适用场景 |测试环境、临时数据、缓存、无状态应用、日志类非关键数据。 |数据库、核心业务数据、需要长期留存的重要数据。 |

容器服务