6.6 持久卷的动态卷配置

作者: 众神开挂 | 来源:发表于2021-07-24 12:16 被阅读0次

6.6 持久卷的动态卷配置

如你所见，使用持久卷和持久卷声明可以轻松获得持久化存储资源，无须研发人员处理下面实际使用的存储技术，但这仍然需要一个集群管理员来支持实际的存储。幸运的是，Kubernetes还可以通过动态配置持久卷来自动执行此任务。

集群管理员可以创建一个持久卷配置，并定义一个或多个StorageClass对象，从而让用户选择他们想要的持久卷类型而不仅仅只是创建持久卷。用户可以在其持久卷声明中引用StorageClass，而配置程序在配置持久存储时将采用这一点。

注意与持久卷类似，StorageClass资源并非命名空间。

Kubernetes包括最流行的云服务提供商的置备程序provisioner，所以管理员并不总是需要创建一个置备程序。但是如果Kubernetes部署在本地，则需要配置定制的置备程序。

与管理员预先提供一组持久卷不同的是，它们需要定义一个或两个（或多个）StorageClass，并允许系统在每次通过持久卷声明请求时创建一个新的持久卷。最重要的是，不可能耗尽持久卷（很明显，你可以用完存储空间）。

6.6.1 通过StorageClass资源定义可用存储类型

在用户创建持久卷声明之前，管理员需要创建一个或多个StorageClass资源，然后才能创建新的持久卷。我们来看下面代码清单中的一个例子。

代码清单6.14 一个StorageClass定义

注意如果使用Minikube，请部署文件storageclass-fast-hostpath.yaml。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: k8s.io/minikube-hostpath
parameters:
  type: pd-ssd

StorageClass资源指定当久卷声明请求此StorageClass时应使用哪个置备程序来提供持久卷。StorageClass定义中定义的参数将传递给置备程序，并具体到每个供应器插件。StorageClass使用GCE持久磁盘的预配置器，这意味着当Kubernetes在GCE中运行时可供使用。对于其他云提供商，需要使用其他的置备程序。

6.6.2 请求持久卷声明中的存储类

创建StorageClass资源后，用户可以在其持久卷声明中按名称引用存储类。

创建一个请求特定存储类的PVC定义

可以修改mongodb-pvc以使用动态配置。以下代码清单显示了PVC中更新后的YAML定义。

代码清单6.15 一个采用动态配置的PVC:mongodb-pvc-dp.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc 
spec:
  storageClassName: fast #该pvc请求自定义存储类
  resources:
    requests:
      storage: 100Mi
  accessModes:
    - ReadWriteOnce

除了指定大小和访问模式，持久卷声明现在还会指定要使用的存储类别。在创建声明时，持久卷由fast StorageClass资源中引用的provisioner创建。即使现有手动设置的持久卷与持久卷声明匹配，也可以使用provisioner。

注意如果在PVC中引用一个不存在的存储类，则PV的配置将失败（在PVC上使用 kubectl describe 时，将会看到ProvisioningFailed事件）。

检查所创建的PVC和动态配置的PV

接着，创建PVC，然后使用kubectl get进行查看：

$ kubectl get pvc mongodb-pvc
NAME          STATUS   VOLUME         CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongodb-pvc   Bound    pvc-38c9014a   100Mi      RWO            fast           2m57s

VOLUME列显示了与此声明绑定的持久卷（实际名称比上面显示的长）。现在可以尝试列出持久卷，看看是否确实自动创建了一个新的PV：

$ kubectl get pv
NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                STORAGECLASS   REASON   AGE
pvc-38c9014a   100Mi      RWO            Delete           Bound    custom/mongodb-pvc   fast                    112s

注意仅显示相关的列。

可以看到动态配置的持久卷其容量和访问模式是在PVC中所要求的。它的回收策略是Delete，这意味着当PVC被删除时，持久卷也将被删除。除了PV，置备程序还提供了真实的存储空间，fast StorageClass被配置为使用 kubernetes.io/gce-pd 从而提供了GCE持久磁盘。可以使用以下命令查看磁盘：

$ gcloud compute disks list

如你所见，第一个持久磁盘的名称表明它是动态配置的，同时它的类型显示为一个SSD，正如在前面创建的存储类中所指定的那样。

了解存储类的使用

集群管理员可以创建具有不同性能或其他特性的多个存储类，然后研发人员再决定对应每一个声明最适合的存储类。

StorageClasses的好处在于，声明是通过名称引用它们的。因此，只要StorageClass名称在所有这些名称中相同，PVC定义便可跨不同集群移植。要自己查看这个可移植性，可以尝试在Minikube上运行相同的示例，假设你一直在使用GKE。作为集群管理员，你必须创建一个不同的存储类（但名称相同）。 storageclass-fast-hostpath.yaml 文件中定义的存储类是专用于Minikube的。然后，一旦部署了存储类，作为集群用户，就可以像以前一样部署完全相同的PVC清单和完全相同的pod清单。这展示了pod和PVC在不同集群间的移植性。

6.6.3 不指定存储类的动态配置

正如我们在本章中所做的那样，将持久性存储附加到pod上变得越来越简单。本章中的章节反映了存储配置是如何从早期的Kubernetes版本发展到现在的。在最后一节中，我们将看看将持久卷附加到pod的最新和最简单的方法。

列出存储类

当你创建名为fast的自定义存储类时，并未检查集群中是否已定义任何现有存储类。现在为什么不这样试试？

除了你自己创建的fast存储类，还存在standard存储类并标记为默认存储类。很快就会知道其含义了，让我们列举Minikube中可用的存储类，以便我们进行比较：

$ kubectl get sc
NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
fast                 k8s.io/minikube-hostpath   Delete          Immediate           false                  9m7s
standard (default)   k8s.io/minikube-hostpath   Delete          Immediate           false                  2d8h

再来看看，fast存储类是由你创建的，并且此处也存在默认的standard存储类，比较两个列表中的TYPE列，你会看到Minikube正在使用 k8s.io/minikube-hostpath 。

检查默认存储类

使用kubectl get可查看有关GKE集群中标准存储类的更多信息，如下面的代码清单所示。

代码清单6.16 GKE上的标准存储类的定义

$ kubectl get sc standard -o yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"labels":{"addonmanager.kubernetes.io/mode":"EnsureExists"},"name":"standard"},"provisioner":"k8s.io/minikube-hostpath"}
    storageclass.kubernetes.io/is-default-class: "true" #此注释将存储类标记为默认
  creationTimestamp: "2021-07-09T00:25:05Z"
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: standard
  resourceVersion: "354"
  uid: 4181e9f0-4a97-4760-8b9f-b9dc77e3fda4
provisioner: k8s.io/minikube-hostpath  #
reclaimPolicy: Delete
volumeBindingMode: Immediate

如果仔细观察清单的顶部，会看到存储类定义会包含一个注释，这会使其成为默认的存储类。如果持久卷声明没有明确指出要使用哪个存储类，则默认存储类会用于动态提供持久卷的内容。

创建一个没有指定存储类别的持久卷声明

可以在不指定storageClassName属性的情况下创建PVC，并且（在Google Kubernetes引擎上）将为你提供一个pd-standard类型的GCE持久磁盘。试试通过下面的代码清单中的YAML来创建一个声明。

代码清单6.17 不指定存储类别的PVC: mongodb-pvc-dp-nostorageclass.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc2 
spec:
  resources:         #没有指定storageClassName属性
    requests: 
      storage: 100Mi
  accessModes:
    - ReadWriteOnce

此PVC定义仅包含存储大小请求和所需访问模式，并不包含存储级别。在创建PVC时，将使用任何标记为默认的存储类。可以通过如下代码确认：

$ kubectl get pvc mongodb-pvc2
$ kubectl get pv pvc-95a5ec12

强制将持久卷声明绑定到预配置的其中一个持久卷

这最后会告诉我们为什么要在代码清单6.11中将storageClassName设置为一个空字符串（当你想让PVC绑定到你手动配置的PV时）。在这里回顾一下这个PVC定义的相关行：

mongodb-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc 
spec:
resources:
 requests:
   storage: 1Gi 
accessModes:
  - ReadWriteOnce  
storageClassName: ""  #将空字符串指定为存储类名可确保pvc绑定到预先配置的PV,而不是动态配置新的PV

如果尚未将storageClassName属性设置为空字符串，则尽管已存在适当的预配置持久卷，但动态卷置备程序仍将配置新的持久卷。此时，笔者想演示一个声明如何绑定到手动预先配置的持久卷，同时不希望置备程序干涉。

提示如果希望PVC使用预先配置的PV，请将storageClassName显式设置为＂＂。

了解动态持久卷供应的全貌

这将我们带到本章的最后。总而言之，将持久化存储附加到一个容器的最佳方式是仅创建PVC（如果需要，可以使用明确指定的storgeClassName）和容器（其通过名称引用PVC），其他所有内容都由动态持久卷置备程序处理。

6.6 持久卷的动态卷配置