Kubernetes - pod 具有未綁定的即時 PersistentVolumeClaims

Question

我正在使用 mysql Kubernetes statefulset，我將 PV 映射到主機目錄（CentOS 8 VM）但得到“pod has unbound直接 PersistentVolumeClaims”

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-container
spec:
  serviceName: mysql
  replicas: 1 
  selector:
    matchLabels:
      app: mysql-container
  template:
    metadata:
      labels:
        app: mysql-container
    spec:
      containers:
      - name: mysql-container
        image: mysql:dev
        imagePullPolicy: "IfNotPresent"
        envFrom:
          - secretRef:
             name: prod-secrets
        ports:
        - containerPort: 3306
         # container (pod) path
        volumeMounts:
          - name: mysql-persistent-storage
            mountPath: /var/lib/mysql


      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
           claimName: mysql-pvc
 volumeClaimTemplates:
    - metadata:
        name: data
      spec:

        storageClassName: localstorage
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 3Gi
        selector:
           matchLabels:
            type: local

存儲類是默認的，PV 中沒有事件

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:

  name: localstorage

provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
reclaimPolicy: Delete
allowVolumeExpansion: True


kind: PersistentVolume
apiVersion: v1
metadata:
  name: mysql-01
  labels:
    type: local
spec:
  storageClassName: localstorage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/mysql01"

---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: mysql-02
  labels:
    type: local
spec:
  storageClassName: localstorage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/mysql02"

存儲類是默認的一個

get sc
NAME                     PROVISIONER                    RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
localstorage (default)   kubernetes.io/no-provisioner   Delete          Immediate           true                   35m

PVC 也沒有顯示任何事件：

    Name:          data-mysql-0
    Namespace:     default
    StorageClass:  localstorage
    Status:        Pending
    Volume:        mysql-storage
    Labels:        app=mysql
    Annotations:   <none>
    Finalizers:    [kubernetes.io/pvc-protection]
    Capacity:      0
    Access Modes:
    VolumeMode:    Filesystem
    Mounted By:    mysql-0
    Events:        <none>


Name:            mysql-01
Labels:          type=local
Annotations:     kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-01"},"spec":{"accessMode...
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    localstorage
Status:          Available
Claim:
Reclaim Policy:  Retain
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        10Gi
Node Affinity:   <none>
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /mnt/mysql01
    HostPathType:
Events:            <none>


Name:            mysql-02
Labels:          type=local
Annotations:     kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-02"},"spec":{"accessMode...
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    localstorage
Status:          Available
Claim:
Reclaim Policy:  Retain
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        10Gi
Node Affinity:   <none>
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /mnt/mysql02
    HostPathType:
Events:            <none>

Pod 處於掛起狀態：

>       Events:
>          Type     Reason            Age                From               Message
>          ----     ------            ----               ----               -------
>          Warning  FailedScheduling  27s (x2 over 27s)  default-scheduler  error while running >"VolumeBinding" filter plugin for pod "mysql-0": pod has unbound immediate PersistentVolumeClaims

有人可以指出這里還應該做什么嗎，謝謝

Answer 1

如果匹配的PersistentVolume不存在，則PersistentVolumeClaims將無限期地保持未綁定狀態。 PersistentVolume與accessModes和capacity相匹配。 在這種情況下， capacity PV 為10Gi而 PVC 的capacity為3Gi 。

PV 中的capacity需要與聲明中的capacity相同，即3Gi以解決unbound immediate PersistentVolumeClaims問題。

Answer 2

提到的錯誤可能有多種原因 - 以下是我遇到的幾個選項。

---

示例 1

persistentvolume-controller未能找到容量大小等於或大於PVC中指定值的PV 。

所以如果我們拿這個例子：

  # PVC
  resources:
     requests:
       storage: 3Gi


  # PV
  capacity:
    storage: 10Gi 

所以：
如果PV capacity >= PVC capacity那么 PVC 應該綁定到 PV。

如果不是，那么在描述 PVC 時，我們將在 pod 級別獲得unbound immediate PersistentVolumeClaims錯誤，並且no volume plugin matched name 。

---

示例 2

PVC的數量高於PV。

例如，如果只創建了一個 PV（或刪除了其他 PV）：

$ kubectl get pv
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                      STORAGECLASS    REASON   AGE
mongo-local-pv   50Gi       RWO            Retain           Bound    default/mongo-persistent-storage-mongo-0   local-storage            106m

我們可以看到一些工作負載（Pods 或 Stateful 集）將卡在待處理狀態：

$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
mongo-0   2/2     Running   0          3m38s
mongo-1   0/2     Pending   0          3m23s

$ kubectl get pvc
NAME                               STATUS    VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS    AGE
mongo-persistent-storage-mongo-0   Bound     mongo-local-pv   50Gi       RWO            local-storage   80m
mongo-persistent-storage-mongo-1   Pending                                              local-storage   45m

我們將在掛起的資源上收到上述錯誤。

---

示例 3

如果調度程序未能將節點與 PV 匹配。

使用本地卷時，需要PV 的nodeAffinity並且應該是集群中現有節點的值：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-mongo-pv
  .
  .
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node-which-doesnt-exists  # <----- Will lead to the error

---

示例 4

集群上已經存在同名不同配置的舊PV ，並根據它們創建新PVC 。

使用本地卷時，管理員必須每次手動清理並重新設置本地卷以供重用。

(*) 創建此本地靜態供應商是為了幫助處理 PV 生命周期。