StorageClass

StorageClass（缩写为SC，没有命名空间隔离性），通过它可以动态管理集群中的PV。

在Kubernetes中，管理员可以只创建StorageClass“链接”到后端不同的存储，比如Ceph、GlusterFS、OpenStack的Cinder、其他公有云提供的存储等

之后有存储需求的技术人员，创建一个PVC指向对应的StorageClass即可，StorageClass会自动创建PV供Pod使用，也可以使用StatefulSet的 volumeClaimTemplate 自动分别为每个Pod申请一个PVC。

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。

StorageClass 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。 当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

默认 StorageClass

当一个 PVC 没有指定 storageClassName 时，会使用默认的 StorageClass。 集群中只能有一个默认的 StorageClass。如果不小心设置了多个默认的 StorageClass， 在动态制备 PVC 时将使用其中最新的默认设置的 StorageClass。

关于如何设置默认的 StorageClass， 请参见更改默认 StorageClass。 请注意，某些云服务提供商可能已经定义了一个默认的 StorageClass。

存储制备器（provisioner）

每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。 该字段必须指定。

回收策略（reclaimPolicy）

由 StorageClass 动态创建的 PersistentVolume 会在StorageClass 对象的 reclaimPolicy 字段中指定回收策略，可以是 Delete 或者 Retain。 如果 StorageClass 对象被创建时没有指定 reclaimPolicy，它将默认为 Delete。

通过 StorageClass 手动创建并管理的 PersistentVolume 会使用它们被创建时指定的回收策略。

允许卷扩展（allowVolumeExpansion）

PersistentVolume 可以配置为可扩展。将此功能设置为 true 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。

当下层 StorageClass 的 allowVolumeExpansion 字段设置为 true 时，以下类型的卷支持卷扩展：

卷类型	Kubernetes 版本要求
rbd	1.11
Azure File	1.11
Portworx	1.11
FlexVolume	1.13
CSI	1.14 (alpha), 1.16 (beta)

说明：

此功能仅可用于扩容卷，不能用于缩小卷。

挂载选项（mountOptions）

由 StorageClass 动态创建的 PersistentVolume 将使用类中 mountOptions 字段指定的挂载选项。

如果卷插件不支持挂载选项，却指定了挂载选项，则制备操作会失败。 挂载选项在 StorageClass 和 PV 上都不会做验证。如果其中一个挂载选项无效，那么这个 PV 挂载操作就会失败。

卷绑定模式（volumeBindingMode）

volumeBindingMode 字段控制了卷绑定和动态制备应该发生在什么时候。 当未设置时，默认使用 Immediate 模式。

Immediate 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。 对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者制备。

集群管理员可以通过指定 WaitForFirstConsumer 模式来解决此问题。 该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。 PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。 这些包括但不限于资源需求、 节点筛选器、 Pod 亲和性和互斥性、 以及污点和容忍度。

如果你选择使用 WaitForFirstConsumer，请不要在 Pod 规约中使用 nodeName 来指定节点亲和性。 如果在这种情况下使用 nodeName，Pod 将会绕过调度程序，PVC 将停留在 pending 状态。

相反，在这种情况下，你可以使用节点选择器作为主机名，如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: kube-01
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

允许的拓扑结构（allowedTopologies）

当集群操作人员使用了 WaitForFirstConsumer 的卷绑定模式， 在大部分情况下就没有必要将制备限制为特定的拓扑结构。 然而，如果还有需要的话，可以使用 allowedTopologies。

这个例子描述了如何将制备卷的拓扑限制在特定的区域， 在使用时应该根据插件支持情况替换 zone 和 zones 参数。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-central-1a
    - us-central-1b

参数（parameters）

Storage Classes 的参数描述了存储类的卷。取决于制备器，可以接受不同的参数。