3. Kubernetes PVC 基础：PersistentVolumeClaim 定义、StorageClass 动态供给、PV 与 PVC 绑定生命周期

在 Kubernetes 存储体系中，PersistentVolumeClaim (PVC) 是用户与存储资源之间的核心抽象层。它解耦了“应用需要什么样的存储”与“底层存储如何提供”这两个关注点。本章将深入剖析 PVC 的定义规范、StorageClass 动态供给机制，以及 PV 与 PVC 绑定的完整生命周期，为后续多集群 etcd 压测沙盘中的 PVC 一致性复核奠定基础。

3.1 PersistentVolumeClaim 定义与结构

PVC 是命名空间级别的资源，用于声明对存储的需求。一个典型的 PVC 定义包含访问模式、资源请求、存储类选择等关键字段。

核心字段说明：
  • accessModes：定义卷的访问模式，决定 Pod 如何挂载该卷。
  • resources.requests.storage：声明所需的最小存储容量。
  • storageClassName：指定要使用的 StorageClass 名称，用于动态供给或匹配已有 PV。
  • selector：通过标签选择器匹配特定 PV，用于静态绑定场景。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: etcd-data-pvc
  namespace: etcd-cluster
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd
  volumeMode: Filesystem
字段 可选值 说明
accessModes ReadWriteOnce / ReadOnlyMany / ReadWriteMany 单节点读写、多节点只读、多节点读写
volumeMode Filesystem / Block 文件系统模式或原始块设备模式
storageClassName 字符串或空 指定 StorageClass 名称；空字符串表示禁用动态供给
selector matchLabels / matchExpressions 用于静态绑定特定 PV

3.2 StorageClass 动态供给机制

StorageClass 是集群管理员定义的存储“模板”，它描述了如何动态创建 PersistentVolume。当 PVC 指定了 storageClassName 时，Kubernetes 控制平面会自动调用对应的 Provisioner 创建 PV 并绑定到 PVC。

最佳实践：在 etcd 压测沙盘中，建议为每个集群配置独立的 StorageClass，并设置 reclaimPolicy: Retain，确保压测结束后数据卷不会被自动删除，便于后续一致性复核。 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
  iopsPerGB: "10"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
StorageClass 参数 作用 压测沙盘推荐值
provisioner 指定存储后端驱动 根据云厂商或本地存储选择
reclaimPolicy PV 释放后的处理策略 Retain（保留数据）
allowVolumeExpansion 是否允许在线扩容 true（便于压测后调整）
volumeBindingMode 绑定时机控制 WaitForFirstConsumer（延迟绑定）
StorageClass 动态供给流程 用户创建 PVC storageClassName: fast-ssd 匹配 StorageClass provisioner: aws-ebs 调用 Provisioner 创建底层存储卷 PV 自动创建 容量、访问模式匹配 PVC PV ↔ PVC 绑定 状态变为 Bound Pod 挂载使用 volumeMounts 引用 PVC 说明： 动态供给流程：用户创建 PVC → 匹配 StorageClass → Provisioner 创建底层卷 → PV 自动生成 → 绑定到 PVC → Pod 挂载。 WaitForFirstConsumer 模式下，PV 创建会延迟到第一个 Pod 调度时触发。

3.3 PV 与 PVC 绑定生命周期

PV 与 PVC 的绑定遵循严格的状态机，从创建到回收经历多个阶段。理解这些状态对于排查 etcd 压测沙盘中的存储问题至关重要。

常见陷阱：在压测沙盘中，如果 PVC 长时间处于 Pending 状态，通常是因为 StorageClass 的 Provisioner 不可用、底层存储配额不足，或者 volumeBindingMode 为 WaitForFirstConsumer 但 Pod 尚未调度。此时应检查 Provisioner Pod 日志和存储后端状态。

3.3.1 绑定状态机

PVC 状态 PV 状态 说明 压测沙盘常见场景
Pending — PVC 已创建，等待匹配 PV 动态供给未完成或 StorageClass 配置错误
Pending Available 存在可用 PV，但未满足绑定条件 访问模式或容量不匹配
Bound Bound PVC 与 PV 成功绑定 正常压测运行状态
Lost Released PV 被用户手动删除或后端卷丢失 etcd 数据卷意外删除后的恢复场景
— Failed PV 自动供给失败 存储配额不足或 Provisioner 异常

3.3.2 绑定条件与规则

Kubernetes 控制平面通过以下条件匹配 PV 与 PVC：

  1. 访问模式匹配：PV 的 accessModes 必须包含 PVC 声明的所有模式。
  2. 容量满足：PV 的容量必须大于等于 PVC 请求的容量。
  3. StorageClass 一致：PVC 的 storageClassName 必须与 PV 的 storageClassName 相同（动态供给场景下自动匹配）。
  4. 标签选择器：如果 PVC 定义了 selector，PV 的标签必须完全匹配。
  5. 卷模式一致：Filesystem 或 Block 模式必须相同。
PV 与 PVC 绑定生命周期状态机 PVC: Pending PVC: Bound PVC: Lost PV: Available PV: Bound PV: Released PV: Failed 动态供给/匹配 绑定完成 PV 删除/后端丢失 PVC 删除 Delete 策略 关键路径： Pending → Bound（正常绑定）→ Lost（异常）→ 人工恢复或重建

3.4 压测沙盘中的 PVC 一致性关注点

在多集群 etcd 压测沙盘中，PVC 的一致性复核需要特别关注以下方面：

一致性复核清单：
  • StorageClass 一致性：所有集群中相同用途的 etcd 数据卷应使用相同的 StorageClass 配置，避免性能差异导致压测结果偏差。
  • 绑定状态一致性：压测前后所有 PVC 应处于 Bound 状态，且绑定到预期的 PV。
  • 容量一致性：实际分配的 PV 容量应与 PVC 请求容量一致，避免因存储后端自动扩展导致容量偏差。
  • 回收策略一致性：所有 etcd 数据卷的 reclaimPolicy 应统一为 Retain，防止压测清理时误删数据。
  • 卷模式一致性：etcd 通常使用 Filesystem 模式，确保所有集群配置一致。
← 上一章 📖 返回目录 下一章 →