Kube.netes Persistent Volume Claim indefinitely in Pending State

Question

我创建了一个 PersistentVolume，它源自我已经格式化并配置了数据的 Google Compute Engine 永久磁盘。 Kube.netes 说 PersistentVolume 可用。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true

然后我创建了一个 PersistentVolumeClaim，这样我就可以将这个卷连接到跨多个节点的多个 pod。 然而，kube.netes 无限期地表示它处于待处理的 state 中。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0

有什么见解吗？ 我觉得选择器可能有问题......

是否有可能预先配置一个包含数据的永久性磁盘，并让跨多个节点的 pod 都能够从中读取数据？

Answer 1

我很快意识到 PersistentVolumeClaim 在未指定时将storageClassName字段默认为standard 。 但是，在创建 PersistentVolume 时， storageClassName没有默认值，因此选择器找不到匹配项。

以下对我有用：

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  storageClassName: standard
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0

Answer 2

使用动态配置，您不必分别创建 PV 和 PVC。 在 Kubernetes 1.6+ 中，有 GKE 和其他一些云环境的默认配置器，它应该让您只需创建一个 PVC 并让它自动为您配置一个 PV 和一个底层 Persistent Disk。

有关动态配置的更多信息，请参阅：

https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes/

Answer 3

如果您使用的是 Microk8s，则必须先启用存储，然后才能成功启动 PersistentVolumeClaim。

只需这样做：

microk8s.enable storage

您需要删除部署并重新开始。

您可能还需要手动删除“待处理”的 PersistentVolumeClaims，因为我发现卸载创建它们的 Helm 图表并没有清除 PVC。

您可以通过首先查找名称列表来执行此操作：

kubectl get pvc --all-namespaces

然后删除每个名称：

kubectl delete pvc name1 name2 etc...

启用存储后，重新应用您的部署应该会让事情顺利进行。

Answer 4

有同样的问题，但这是另一个原因，这就是我在这里分享它以帮助社区的原因。

如果您删除了PersistentVolumeClaim然后使用相同的定义重新创建它，它将永远挂起，为什么？

在PersistentVolume persistentVolumeReclaimPolicy默认为Retain 。 如果我们删除了PersistentVolumeClaim ，则PersistentVolume仍然存在并且该卷被视为已释放。 但它尚不可用于其他索赔，因为前一个索赔人的数据仍保留在卷上。 因此您需要通过以下步骤手动回收卷：

1. 删除 PersistentVolume（相关的底层存储资产/资源，如 EBS、GCE PD、Azure 磁盘等将不会被删除，仍然存在）

2. （可选）相应地手动清理关联存储资产上的数据

3. （可选）手动删除关联的存储资产（EBS、GCE PD、Azure 磁盘等）

如果您仍然需要相同的数据，您可以跳过清理和删除关联的存储资产（上面的第 2 步和第 3 步），因此只需简单地重新创建一个具有相同存储资产定义的新PersistentVolume ，那么您应该可以再次创建PersistentVolumeClaim 。

最后要提到的一件事， Retain不是persistentVolumeReclaimPolicy的唯一选项，以下是您可能需要根据用例场景使用或尝试的一些其他选项：

回收：对卷执行基本清理（例如， rm -rf //* ） - 使其再次可用于新的声明。 只有NFS和HostPath支持回收。

删除：删除关联的存储资产，例如AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder...etc卷

有关更多信息，请查看kubernetes 文档。

仍然需要更多说明或有任何疑问，请随时发表评论，我将非常乐意澄清和提供帮助。

Answer 5

我遇到了同样的问题，并意识到 k8s 实际上做了一个即时供应，即

• 当一个 pvc 被创建时，它一直处于 PENDING 状态，并且没有相应的 pv 被创建。
• pvc & pv（EBS 卷）仅在您创建使用 pvc 的部署后创建。

我将 EKS 与 kubernetes 1.16版一起使用，行为由StorageClass Volume Binding Mode 控制。

Answer 6

当两个PersistentVolume的spec/hostPath/path值相同时，我在microk8s 1.14.1 中看到了这种行为，例如

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-name
  labels:
    type: local
    app: app
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/k8s-app-data"

microk8s 似乎是基于事件的（这在单节点集群上不是必需的）并且会丢弃有关任何失败操作的信息，从而导致几乎所有失败的不必要的可怕反馈。

Answer 7

我在 apache 气流（稳定）的 helmchart 上遇到了这个问题，将 storageClass 设置为 azurefile 有帮助。 在这种情况下，您应该对云提供商做什么？ 只需搜索支持所需访问模式的存储类。 ReadWriteMany 意味着同时许多进程将读取和写入存储。 在这种情况下（azure）它是 azurefile。

path: /opt/airflow/logs

  ## configs for the logs PVC
  ##
  persistence:
    ## if a persistent volume is mounted at `logs.path`
    ##
    enabled: true

    ## the name of an existing PVC to use
    ##
    existingClaim: ""

    ## sub-path under `logs.persistence.existingClaim` to use
    ##
    subPath: ""

    ## the name of the StorageClass used by the PVC
    ##
    ## NOTE:
    ## - if set to "", then `PersistentVolumeClaim/spec.storageClassName` is omitted
    ## - if set to "-", then `PersistentVolumeClaim/spec.storageClassName` is set to ""
    ##
    storageClass: "azurefile"

    ## the access mode of the PVC
    ##
    ## WARNING:
    ## - must be: `ReadWriteMany`
    ##
    ## NOTE:
    ## - different StorageClass support different access modes:
    ##   https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
    ##
    accessMode: ReadWriteMany

    ## the size of PVC to request
    ##
    size: 1Gi

Answer 8

我正在使用 microk8s

通过运行以下命令修复了问题

systemctl start open-iscsi.service

Answer 9

当您想手动将 PVC 绑定到具有现有磁盘的 PV 时，不应指定storageClassName<\/code> ...但是...云提供商默认设置了“标准” StorageClass，使其始终输入您在修补时尝试的任何内容聚氯乙烯\/光伏。

您可以在执行kubectl get storageclass<\/code>时检查您的提供程序是否将其设置为默认值（它将被写为“（默认”））。

要解决此问题，最好的方法是获取现有的 StorageClass YAML 并添加此注释：

  annotations:
    storageclass.kubernetes.io/is-default-class: "false"

Answer 10

我有同样的问题。 我的PersistentVolumeClaim yaml原来是这样的：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  storageClassName: “”
  accessModes:
    – ReadWriteOnce 
  volumeName: pv
  resources:
    requests:
      storage: 1Gi

我的 PVC 状态是：

删除volumeName后：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  storageClassName: “”
  accessModes:
    – ReadWriteOnce 
  resources:
    requests:
      storage: 1Gi

Answer 11

我遇到了同样的问题，其中 PersistentVolumeClaim 无限期地处于待定阶段，我尝试在 PersistentVolume 中提供 storageClassName 作为“默认”，就像我为 PersistentVolumeClaim 所做的那样，但它没有解决这个问题。

我在我的persistentvolume.yml 中做了一个更改并将PersistentVolumeClaim 配置移到文件的顶部，然后将PersistentVolume 作为yml 文件中的第二个配置。 它已经解决了这个问题。

我们需要确保首先创建 PersistentVolumeClaim，然后创建 PersistentVolume 以解决此“待处理”阶段问题。

我在测试了几次后发布了这个答案，希望它可以帮助那些与之抗争的人。

Answer 12

确保您的 VM 也有足够的磁盘空间。