使用 Persistent Volume Claim 时是否必须显式创建 Persistent Volume？

Question

我是 Kubernetes 新手，我很难理解 Kubernetes 中持久存储背后的整个想法。

这样就够了，或者我必须创建 Persistent Volume，如果我只部署这两个对象而不创建 PV，会发生什么？

存储应该在本地机器上。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  name: nginx-logs
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
status: {}

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: app-web
  name: app-web
spec:
  selector:
    matchLabels:
      app: app-web
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: app-web
    spec:
      containers:
        image: nginx:1.14.2
        imagePullPolicy: Always
        name: app-web
        volumeMounts:
        - mountPath: /var/log/nginx
          name: nginx-logs
      restartPolicy: Always
      volumes:
      - name: nginx-logs
        persistentVolumeClaim:
          claimName: nginx-logs

Answer 1

我很难理解 Kubernetes 中持久存储背后的整个想法

这个想法是将应用所需的存储请求和物理存储分开 - 这样应用就可以移动到例如其他具有不同存储系统的云提供商 - 但不需要对应用程序进行任何更改。它还分离了“请求存储”和管理底层存储的责任，例如开发人员与运营人员。

这样就够了，或者我必须创建 Persistent Volume，如果我只部署这两个对象而不创建 PV，会发生什么？

这取决于您的环境。大多数环境通常有Dynamic Volume Provisioning，例如大型云提供商，现在 Minikube 也对此提供支持。

使用动态卷配置时，开发人员只需创建一个 PersistentVolumeClaim - 而不是 PersistentVolume，而是动态配置。

Answer 2

需要在capacity(100Mi) 和accessModes(ReadWriteOnce) 方面与PVC 匹配的PV。如果您没有PV，则会收到错误pod has unbound immediate PersistentVolumeClaims。因此，您要么手动创建 PV（称为静态配置），要么依靠存储类和卷驱动程序自动创建（称为动态配置）。

PV 是卷的 kubernetes 表示。实际的卷仍需要配置。如果您使用 dynamic volume provisioning 并且您的云提供商有卷驱动程序，则配置由驱动程序在内部自动执行，无需手动创建 PV。

在本地非云系统中，您可以使用local path provisioner 来使用动态配置。配置默认storage class，可以避免手动创建PV。

Answer 3

您可以在 the doc 中看到它提到了一种动态配置持久卷的方式。

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim，集群可能会尝试动态配置一个 PVC 专用卷。此配置基于 StorageClasses：PVC 必须请求一个存储类，并且 管理员必须为动态创建并配置该类 供应发生。有效地请求类“”的声明 为自己禁用动态配置。

当我应用你的 pvc 时，它会创建一个 gp2 卷，因为这是我的默认存储类。

$kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nginx-logs   Bound    pvc-b95a9d0c-ef46-4ff0-a034-d2dde1ac1f96   1Gi        RWO            gp2            6s

你可以像这样看到你的默认存储类

$kubectl get storageclass
NAME            PROVISIONER                                           AGE
gp2 (default)   kubernetes.io/aws-ebs                                 355d

您还可以包含特定的存储类。你可以阅读更多关于here的信息。

用户通过包含存储来请求动态配置的存储 PersistentVolumeClaim 中的类

简而言之，您当前的 pvc 文件将使用您的默认存储类来创建一个持久卷，然后您通过部署中的持久卷声明将该卷挂载到您的 pod 中。