PersistentVolumeClaims

每个 PVC 对象都有 spec 和 status 部分，分别对应申领的规约和状态。 PersistentVolumeClaim 对象的名称必须是合法的 DNS 子域名.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Access Modes

申领在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定。

Volume Modes

申领使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。

Resources

申领和 Pod 一样，也可以请求特定数量的资源。在这个上下文中，请求的资源是存储。 卷和申领都使用相同的 资源模型。

Selector

申领可以设置标签选择算符 来进一步过滤卷集合。只有标签与选择算符相匹配的卷能够绑定到申领上。 选择算符包含两个字段：

• matchLabels - 卷必须包含带有此值的标签
• matchExpressions - 通过设定键（key）、值列表和操作符（operator） 来构造的需求。合法的操作符有 In、NotIn、Exists 和 DoesNotExist。

来自 matchLabels 和 matchExpressions 的所有需求都按逻辑与的方式组合在一起。 这些需求都必须被满足才被视为匹配。

Class

pvc可以通过为 storageClassName 属性设置 StorageClass 的名称来请求特定的存储类。 只有所请求的类的 PV 卷，即 storageClassName 值与 PVC 设置相同的 PV 卷， 才能绑定到 PVC 申领。

PVC 申领不必一定要请求某个类。如果 PVC 的 storageClassName 属性值设置为 ""， 则被视为要请求的是没有设置存储类的 PV 卷，因此这一 PVC 申领只能绑定到未设置存储类的 PV 卷（未设置注解或者注解值为 "" 的 PersistentVolume（PV）对象在系统中不会被删除， 因为这样做可能会引起数据丢失。未设置 storageClassName 的 PVC 与此大不相同， 也会被集群作不同处理。具体筛查方式取决于 DefaultStorageClass 准入控制器插件 是否被启用。

• 如果准入控制器插件被启用，则管理员可以设置一个默认的 StorageClass。 所有未设置 storageClassName 的 PVC 都只能绑定到隶属于默认存储类的 PV 卷。 设置默认 StorageClass 的工作是通过将对应 StorageClass 对象的注解 storageclass.kubernetes.io/is-default-class 赋值为 true 来完成的。 如果管理员未设置默认存储类，集群对 PVC 创建的处理方式与未启用准入控制器插件时相同。 如果设定的默认存储类不止一个，准入控制插件会禁止所有创建 PVC 操作。
• 如果准入控制器插件被关闭，则不存在默认 StorageClass 的说法。 所有将 storageClassName 设为 "" 的 PVC 只能被绑定到也将 storageClassName 设为 "" 的 PV。 不过，只要默认的 StorageClass 可用，就可以稍后更新缺少 storageClassName 的 PVC。 如果这个 PVC 更新了，它将不再绑定到也将 storageClassName 设为 "" 的 PV。

参阅可追溯的默认 StorageClass 赋值了解更多详细信息。

取决于安装方法，默认的 StorageClass 可能在集群安装期间由插件管理器（Addon Manager）部署到集群中。

当某 PVC 除了请求 StorageClass 之外还设置了 selector，则这两种需求会按逻辑与关系处理： 只有隶属于所请求类且带有所请求标签的 PV 才能绑定到 PVC。

说明：

目前，设置了非空 selector 的 PVC 对象无法让集群为其动态制备 PV 卷。

早前，Kubernetes 使用注解 volume.beta.kubernetes.io/storage-class 而不是 storageClassName 属性。这一注解目前仍然起作用，不过在将来的 Kubernetes 发布版本中该注解会被彻底废弃。

可追溯的默认 StorageClass 赋值

特性状态： Kubernetes v1.26 [beta]

你可以创建 PersistentVolumeClaim，而无需为新 PVC 指定 storageClassName。 即使你的集群中不存在默认 StorageClass，你也可以这样做。 在这种情况下，新的 PVC 会按照你的定义进行创建，并且在默认值可用之前，该 PVC 的 storageClassName 保持不设置。

当一个默认的 StorageClass 变得可用时，控制平面会识别所有未设置 storageClassName 的现有 PVC。 对于 storageClassName 为空值或没有此主键的 PVC， 控制平面会更新这些 PVC 以设置其 storageClassName 与新的默认 StorageClass 匹配。 如果你有一个现有的 PVC，其中 storageClassName 是 ""， 并且你配置了默认 StorageClass，则此 PVC 将不会得到更新。

为了保持绑定到 storageClassName 设为 "" 的 PV（当存在默认 StorageClass 时）， 你需要将关联 PVC 的 storageClassName 设置为 ""。

此行为可帮助管理员更改默认 StorageClass，方法是先移除旧的 PVC，然后再创建或设置另一个 PVC。 这一时间窗口内因为没有指定默认值，会导致所创建的未设置 storageClassName 的 PVC 也没有默认值设置， 但由于默认 StorageClass 赋值是可追溯的，这种更改默认值的方式是安全的。