Kubernetes 永久卷声明无限期处于待处理状态答案

【问题标题】：Kubernetes Persistent Volume Claim Indefinitely in Pending StateKubernetes 永久卷声明无限期处于待处理状态
【发布时间】：2022-02-01 22:10:45
【问题描述】：

我创建了一个来自 Google Compute Engine 永久磁盘的 PersistentVolume，我已经格式化并提供了数据。 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。但是，kubernetes 无限期地表示它处于待处理状态。

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 都可以从中读取数据？

【问题讨论】：

标签： kubernetes persistent-volumes persistent-volume-claims

【解决方案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

【讨论】：

运行kubectl describe pvc 确认这是否是错误，你会得到"Cannot bind to requested volume "YOUR_PV_NAME": storageClasseName does not match"
有同样的问题。奇怪的是k8仪表板只是保持挂起而不报告错误！
+1 在使用 kops 的 AWS EC2 集群设置上也遇到了这个问题。为了使 PV/PVC 正确连接，我必须将 storageClassName: gp2 添加到两者中。 setting a storage class 上有一些相关文档用于您的 AWS 集群和 types of EBS volumes available 出于某种原因，我没有收到 @s12chung 指出的错误消息

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

只要做：

microk8s.enable storage

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

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

您可以通过首先查找名称列表来做到这一点：

kubectl get pvc --all-namespaces

然后删除每个名称：

kubectl delete pvc name1 name2 etc...

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

【讨论】：

在 microk8s/ubuntu 19.10 中像魅力一样工作
在 Ubuntu 20.04 上使用 microk8s 为我工作。
注意不要删除其他pvc，第一条评论会显示所有进程中所有现有的pvc。
天哪，这个响应在整个互联网上都是顶级的！谢谢兄弟，让我前进

【解决方案4】：

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

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

persistentVolumeReclaimPolicy 在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 Disk, or OpenStack Cinder...etc 卷

欲了解更多信息，请查看kubernetes documentation。

仍需要更多澄清或有任何问题，请随时发表评论，我将非常乐意澄清和协助。

【讨论】：

只删除PV中的数据就可以解决这个问题吗？由于某些限制，我无法删除 PV 并创建新 PV。但由于我删除了 PVC，我无法创建一个新的并显示为待处理状态
@iRunner 您不必删除数据本身，但您仍然必须删除 PV（逻辑卷不是实际数据）-（不要担心，如果您决定关联的底层存储不会被删除删除 PV)
@MuhammadSoliman 如果我无权访问 PV，因为您需要集群管理员权限才能删除，那么应该怎么做？我正在寻找的行为是；如果我删除 pvc，那么我想让 pv 再次可用于另一个索赔。还是您建议只删除 pod 并保持 pvc 完整，以便再次在 pod 中重复使用？

【解决方案5】：

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

创建pvc时，一直处于PENDING状态，没有创建对应的pv。
pvc 和 pv（EBS 卷）仅在您创建使用 pvc 的部署后创建。

我正在使用带有 kubernetes 版本 1.16 的 EKS，并且行为由 StorageClass Volume Binding Mode 控制。

【讨论】：

【解决方案6】：

当两个PersistentVolumes 对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 是基于事件的（这在单节点集群上不是必需的）并且会丢弃有关任何失败操作的信息，从而导致对几乎所有失败的不必要的可怕反馈。

【讨论】：

【解决方案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

【讨论】：

【解决方案8】：

当您想手动将 PVC 绑定到具有现有磁盘的 PV 时，不应指定 storageClassName...但是...云提供商默认设置了“标准”StorageClass，使其始终输入修补 PVC/PV 时无论您尝试什么。

您可以在kubectl get storageclass 时检查您的提供商是否将其设置为默认值（它将被写为“（默认”））。

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

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

申请好:)

【讨论】：

【解决方案9】：

我正在使用 microk8s

通过运行以下命令解决了问题

systemctl start open-iscsi.service

（之前使用 apt install open-iscsi 安装了 open-iscsi，但尚未启动）

然后按如下方式启用存储

microk8s.enable storage

然后，从 Lens 中删除 Stateful Sets 和待处理的 Persistence Volume Claims，以便重新开始。

之后效果很好。

【讨论】：

【解决方案10】：

我遇到了 PersistentVolumeClaim 无限期处于 Pending Phase 的相同问题，我尝试在 PersistentVolume 中将 storageClassName 提供为“默认”，就像我为 PersistentVolumeClaim 所做的那样，但它没有解决这个问题。

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

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

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

【讨论】：

我发现Pending阶段过长并不是两个组件的创建顺序造成的。我按照您的建议进行了尝试，它分配的速度快了大约 2 秒。在我的情况下，根本原因是在使用 storageClassName: storage 时将 ReadWriteMany 替换为 ReadWriteOnce

【解决方案11】：

确保您的虚拟机也有足够的磁盘空间。

【讨论】：