K8S中的存储-搞清pv和pvc

Kubernetes 的存储体系概念繁多且容易混淆，什么sc、pv、pvc及其各种配置，还有各种存储类型nas、nfs、csi、sfs等等。这里记录一下，可以反复阅读深刻记录，也方便遗忘之后进行复查～

一、 核心抽象层 (Kubernetes)

1. PersistentVolume (PV)

是什么？ 集群中的一块网络存储。是集群的资源，就像节点(Node)一样。PV 是独立于 Pod 的生命周期的、由管理员配置提供的存储资源。

• 关键点： PV 是集群级别的资源，不属于任何命名空间。

常见配置：

• capacity.storage: 存储大小
• accessModes: 访问模式 (见核心QA5)
• persistentVolumeReclaimPolicy: 回收策略 (见核心QA6)
• storageClassName: 所属的 StorageClass
• 后端存储类型 (如 NFS, CSI, Ceph 等) 的具体配置

2. PersistentVolumeClaim (PVC)

是什么？ 用户对存储的请求。它类似于 Pod。Pod 消耗节点资源，而 PVC 消耗 PV 资源。

• 关键点： PVC 是命名空间级别的资源。Pod 通过在其所在命名空间中挂载 PVC 来使用存储。

常见配置：

• resources.requests.storage: 申请的存储大小
• accessModes: 所需的访问模式 (必须与 PV 匹配)
• storageClassName: 指定由哪个 StorageClass 来动态制备 PV

3. StorageClass (SC)

是什么？ 存储类的抽象。它定义了如何动态制备 PV，即“创建 PV 的模板”。它允许管理员描述他们提供的存储的“类别”，而不是具体细节。

• 关键点： 用于动态存储分配。当用户创建 PVC 并指定一个 SC 时，系统会自动按 SC 的模板创建一个合适的 PV 并绑定给该 PVC。

常见配置：

• provisioner: 决定由谁来创建 PV（例如 nas.csi.alibabacloud.com, efs.csi.aws.com）。
• parameters: 传递给 provisioner 的参数（例如 server: "nas-xxx.cn-hangzhou.nas.aliyuncs.com", path: "/share"）。

4.Container Storage Interface(CSI)

是什么？ 一个标准接口，不是一种存储系统。Kubernetes 通过 CSI 来对接外部的存储系统（如阿里云 NAS、AWS EFS、Ceph 等）。我们安装的 alibaba-cloud-csi-driver 就是一个 CSI 驱动，它让 Kubernetes 能够使用阿里云的存储服务，具体如下：

• Disk：diskplugin.csi.alibabacloud.com，块存储（RWO），支持快照、扩容等。
• NAS：nasplugin.csi.alibabacloud.com，网络文件存储（RWX），但不支持动态扩容。
• OSS（对象存储）：ossplugin.csi.alibabacloud.com，用于对象存储（RWX，不支持动态扩容）。

二、 后端存储类型 (实际提供存储的系统)

这些是具体的存储服务或协议，PV/SC 需要通过它们来实现。

• NFS (Network File System): 一种标准的网络文件共享协议。简单易用，适合多读多写场景。
• NAS (Network Attached Storage): 网络附加存储。在云上，NAS 服务通常通过 NFS 或 SMB 协议提供访问。所以常说“用 NFS 协议挂载阿里云 NAS”。
• SFS (Scalable File Service) / Turbo (极速型):
  • SFS： 华为云的弹性文件服务名称。
  • Turbo： 阿里云 NAS 的高性能（通常基于 Lustre）文件存储类型。SFS Turbo 也是华为云的高性能文件服务。
  • 它们本质上都是托管的、高性能的 NAS 服务。

三、 核心QA

这些搞明白了，基本就通了

1. SC (StorageClass) 可以定义 NAS 吗？

可以。 SC 的 provisioner 字段会指定为 NAS 的 CSI 驱动（例如 nas.csi.alibabacloud.com），并在 parameters 中配置 NAS 的服务器地址、子路径等参数。这样，SC 就成为了一个“NAS 存储类”，申请该 SC 的 PVC 就会自动创建出基于阿里云 NAS 的 PV。

2. PV 可以跨命名空间吗？

PV 本身是集群级别的，可以被任何命名空间的 PVC 绑定。

• 静态制备： 管理员先创建 PV，PVC 再与之绑定。只要 PV 的 accessModes 等其他条件匹配，不同命名空间的 PVC 都可以绑定它（但一个 PV 只能被一个 PVC 绑定）。
• 动态制备： PVC 通过 SC 动态创建 PV，创建的 PV 会自动与创建该 PVC 的命名空间绑定，其他命名空间的 PVC 无法使用它。

3. 一块 NAS 可以定义为不同的 PV 吗？

完全可以，而且这是最佳实践。
一块 NAS 文件系统（例如 nas-xxx.cn-hangzhou.nas.aliyuncs.com）是一个大的存储池。可以在其下创建多个目录（例如 /data/mysql, /data/nginx）。

• 为每个目录创建一个 PV/PVC（通过 subpath 或直接在 SC 中指定不同的 path）。
• 这样实现了存储资源的隔离和复用，多个应用可以安全地共享同一台 NAS 服务器而互不干扰。

4. subpath 什么时候使用？

在 Pod 的 volumes 定义中，想将 PVC 中的一个子目录挂载到容器中，而不是整个卷时使用。

使用场景：

• 一个 PVC/PV 对应一块大的 NAS 存储，上面有 app1-data, app2-data 两个目录。
• Pod 只需要使用 app1-data 目录。
• 可以在 volumeMounts 中这样配置：

  volumeMounts:
  - name: mypvc
    mountPath: "/app/data"
    subPath: "app1-data" # 只挂载PVC中的app1-data子目录
  

5. AccessModes (访问模式)

定义 PV 的访问权限，PVC 必须匹配 PV 的模式。

• ReadWriteOnce (RWO)： 可读可写，只能被单个节点挂载。 ，适用于如数据库等需要单节点读写访问的应用。大部分块存储（如云盘）属于此类。
• ReadOnlyMany (ROX)： 只读，可被多个节点挂载。
• ReadWriteMany (RWX)： 可读可写，可被多个节点同时挂载。适用于需要多节点同时写入的应用，如网站共享目录、AI 训练共享模型等。NFS/NAS/SFS 等文件存储通常支持此模式。
• ReadWriteOncePod (RWOP) (Kubernetes v1.22+)： 可读可写，但只能被单个 Pod 挂载（确保 Pod 唯一性访问）。适用于需要单 Pod 独占式访问的安全敏感场景。

6. persistentVolumeReclaimPolicy (回收策略)

当绑定该 PV 的 PVC 被删除后，PV 本身该如何处理。

• Retain（保留）：
  • 行为： PV 被释放（Released），但数据和 PV 资源都保留在系统中。管理员可以手动清理数据并删除 PV。
  • 使用场景： 数据非常重要，需要手动处理。静态制备的 PV 默认为此策略。
• Delete（删除）：
  • 行为： PV 对象会被自动删除，同时后端存储（如云盘、NAS）也会被自动删除，数据丢失！
  • 使用场景： 动态制备的存储，希望随 PVC 删除而自动销毁， 。动态制备的 PV 默认为此策略，使用时务必小心！
• Recycle（回收）（已废弃）： 基本不再使用。

7. StorageClass 什么时候使用？

绝大多数生产环境都应使用 StorageClass 进行动态存储分配。

• 使用场景： 需要为每个应用按需、自动地创建一块存储时。

  • 用户只需提交 PVC（声明需要 10Gi RWX 的存储），Kubernetes 和 CSI 驱动会自动调用云厂商 API，创建出对应的 NAS 并生成 PV。
  • 优点： 无需管理员预先创建 PV，自动化程度高，按需取用，不易浪费。

• 不使用场景（静态绑定）： 管理员手动维护 PV 和底层存储（如自己搭建的 NFS 服务器）。当有 PVC 申请时，Kubernetes 只是将其与已存在的、合适的 PV 进行绑定。

四、 总结与记忆技巧

一句话记忆：
用户创建 PVC（申请单），系统通过 SC（模板）动态生成 PV（磁盘）并绑定，Pod 挂载 PVC，CSI（驱动程序）最终将请求转发给底层的 NAS/NFS（共享存储）进行实际的数据读写，对应着PVC制备工作流如下：

pvc创建流程

参考资源：

• 阿里云-ACK-存储基础知识
• 华为云-CCE-存储基础知识