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 也有足夠的磁盤空間。