Kubernetes持久卷声明无限期处于挂起状态_Kubernetes_Persistent Volumes_Persistent Volume Claims

Kubernetes持久卷声明无限期处于挂起状态

kubernetes

Kubernetes持久卷声明无限期处于挂起状态,kubernetes,persistent-volumes,persistent-volume-claims,Kubernetes,Persistent Volumes,Persistent Volume Claims,我创建了一个PersistentVolume，它源于一个Google Compute Engine持久化磁盘，我已经格式化并提供了数据。Kubernetes说PersistentVolume是可用的 kind: PersistentVolume apiVersion: v1 metadata: name: models-1-0-0 labels: name: models-1-0-0 spec: capacity: storage: 200Gi accessMod

我创建了一个PersistentVolume，它源于一个Google Compute Engine持久化磁盘，我已经格式化并提供了数据。Kubernetes说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。然而，库伯内特斯无限期地说，它处于未决状态

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都能够从中读取数据吗？

我很快意识到，如果未指定，PersistentVolumeClaim将

存储类名称

字段默认为

标准。但是，在创建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

使用动态资源调配，您不必分别创建PV和PVC。在Kubernetes 1.6+中，有用于GKE和其他一些云环境的默认供应器，它应该允许您创建一个PVC，并让它自动为您供应一个PV和一个底层持久磁盘
有关动态资源调配的详细信息，请参阅：
我遇到了与PersistentVolumeClaim无限期处于挂起阶段相同的问题，我尝试在PersistentVolume中提供storageClassName作为“默认值”，就像我为PersistentVolumeClaim所做的一样，但它没有解决此问题
我在persistentvolume.yml中做了一个更改，并将PersistentVolumeClaim配置移到文件的顶部，然后将persistentvolume作为yml文件中的第二个配置。它已经解决了这个问题
我们需要确保先创建PersistentVolumeClaim，然后再创建PersistentVolume，以解决此“挂起”阶段问题
在测试了几次之后，我发布了这个答案，希望它能帮助那些正在努力解决这个问题的人。
我在microk8s
1.14.1中看到过这种行为，例如，当两个PersistentVolume
s对于spec/hostPath/path具有相同的值时
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是基于事件的（在单节点群集上不需要），并且会丢弃有关任何失败操作的信息，从而导致几乎所有失败的不必要的可怕反馈。
确保您的虚拟机也有足够的磁盘空间。
如果您使用microk8s，在成功启动PersistentVolumeClaim之前，必须启用存储
只要做：
microk8s.enable storage

您需要删除部署并重新开始
您可能还需要手动删除“挂起”PersistentVolumeClaims，因为我发现卸载创建它们的头盔图表并没有清除PVC
您可以通过首先查找名称列表来执行此操作：
kubectl get pvc --all-namespaces

然后使用以下命令删除每个名称：
kubectl delete pvc name1 name2 etc...

一旦启用了存储，重新应用您的部署应该会让事情顺利进行。
也有同样的问题，但这也是我在这里分享它以帮助社区的另一个原因
如果删除了PersistentVolumeClaim
，然后使用相同的定义重新创建它，它将永远挂起，为什么
persistentVolumeClaincolicy
在PersistentVolume
中默认为Retain
。如果我们删除了PersistentVolumeClaim
，则PersistentVolume仍然存在，并且该卷被视为已发布。但由于前一位索赔人的数据仍保留在该卷上，因此还不能用于另一项索赔。
因此，您需要通过以下步骤手动回收卷：
删除PersistentVolume（关联的基础存储资产/资源（如EBS、GCE PD、Azure磁盘等）不会被删除，但仍然存在）

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

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

如果仍然需要相同的数据，可以跳过清理和删除关联的存储资产（上面的步骤2和步骤3），因此只需使用相同的存储资产定义重新创建一个新的PersistentVolume
，就可以再次创建PersistentVolumeClaim

最后要提到的一点是，Retain
不是persistentVolumeReclaimPolicy
的唯一选项，下面是一些其他选项，您可能需要根据用例场景使用或尝试：
回收：对卷执行基本清理（例如，rm-rf/*
）-使其再次可用于新的声明。只有NFS
和HostPath
支持回收
删除：删除关联的存储资产，如AWS EBS、GCE PD、Azure磁盘或OpenStack Cinder…等
卷
有关更多信息，请查看
仍然需要更多的澄清或有任何问题，请不要犹豫留下评论，我将非常乐意澄清和帮助。
我也面临同样的问题，并且意识到k8s实际上提供了及时的服务，即

创建pvc时，它将保持挂起状态，并且不会创建相应的pv
pvc&pv（EBS卷）仅在创建使用pvc的部署后创建

我将EKS与kubernetes版本一起使用1.16
，其行为由控制。
我在apache airflow的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

运行kubectl描述pvc
t