WaitForFirstConsumer PersistentVolumeClaim ожидает создания первого потребителя перед привязкой

Я установил новый k8s в одном узле, который испорчен. Но PersistentVolume не может быть успешно создан, когда я пытаюсь создать простой PostgreSQL.

Ниже приведена некоторая подробная информация.

StorageClass скопировано с официальной страницы: https://kubernetes.io/docs/concepts/storage/storage-classes/#local

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

StatefulSet это:

kind: StatefulSet
apiVersion: apps/v1beta1
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  ...
  volumeClaimTemplates:
    - metadata:
        name: postgres-data
      spec:
        storageClassName: local-storage
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

О бегущей StorageClass:

$ kubectl describe storageclasses.storage.k8s.io
Name:            local-storage
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"local-storage"},"provisioner":"kubernetes.io/no-provisioner","volumeBindingMode":"WaitForFirstConsumer"}

Provisioner:           kubernetes.io/no-provisioner
Parameters:            <none>
AllowVolumeExpansion:  <unset>
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     WaitForFirstConsumer
Events:                <none>

О бегущей PersistentVolumeClaim:

$ kubectl describe pvc
Name:          postgres-data-postgres-0
Namespace:     default
StorageClass:  local-storage
Status:        Pending
Volume:
Labels:        app=postgres
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Events:
  Type       Reason                Age                            From                         Message
  ----       ------                ----                           ----                         -------
  Normal     WaitForFirstConsumer  <invalid> (x2 over <invalid>)  persistentvolume-controller  waiting for first consumer to be created before binding

Версии K8s:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

kubernetes persistent-volumes
person Yan QiDong    schedule 07.03.2019    source источник

Ответы (6)


arrow_upward
11
arrow_downward

Приложение ожидает Pod, в то время как Pod ожидает PersistentVolume от PersistentVolumeClaim. Однако PersistentVolume должен быть подготовлен пользователем перед использованием.

В моих предыдущих YAML отсутствует PersistentVolume, например:

kind: PersistentVolume
apiVersion: v1
metadata:
  name: postgres-data
  labels:
    type: local
spec:
  storageClassName: local-storage
  capacity:
    storage: 1Gi
  local:
    path: /data/postgres
  persistentVolumeReclaimPolicy: Retain
  accessModes:
    - ReadWriteOnce
  storageClassName: local-storage
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: app
            operator: In
            values:
              - postgres

Локальный путь /data/postgres должен быть подготовлен перед использованием. Kubernetes не создаст его автоматически.

person Yan QiDong    schedule 09.03.2019
comment
Вам нужен nodeAffinity? - person Justin Thomas; 14.08.2019
comment
Для local-storage, я думаю, необходимо nodeAffinity. Я не хочу, чтобы PersistentVolume был запланирован где-либо. - person Yan QiDong; 15.08.2019
comment
@YanQiDong Я не могу это решить. Я получаю 0/2 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) had taints that the pod didn't tolerate при описании pod postgre. Ты можешь взять меня? - person Akashii; 04.11.2019
comment
Контейнер можно запланировать только на тот узел, где находится локальное хранилище PV. - person Yan QiDong; 14.11.2019

arrow_upward
2
arrow_downward

Я только что столкнулся с этим сам и был полностью зациклен, пока не понял, что StorageClass VolumeBindingMode было установлено на WaitForFirstConsumer, а не на мое предполагаемое значение Immediate. Это значение является неизменным, поэтому вам придется:

  1. Получите класс хранения yaml:

    kubectl get storageclasses.storage.k8s.io gp2 -o yaml > gp2.yaml

    или вы также можете просто скопировать пример из здесь (убедитесь, что имена метаданных совпадают). Вот что я настроил:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

  2. И удалите старый StorageClass перед его воссозданием с новым volumeBindingMode, установленным на Immediate.

Примечание. Кластеру EKS могут потребоваться разрешения для создания облачных ресурсов, таких как EBS или EFS. Предполагая, что EBS у вас должно быть хорошо с arn:aws:iam::aws:policy/AmazonEKSClusterPolicy.

После этого у вас не должно возникнуть проблем с созданием и использованием динамически подготовленных PV.

person Robert J    schedule 19.10.2020

arrow_upward
1
arrow_downward

Принятый ответ не сработал для меня. Я думаю, это связано с тем, что ключ приложения не будет установлен до того, как StatefulSet будут развернуты Pods, что не позволит PersistentVolumeClaim соответствовать < em>nodeSelector (предотвращает запуск Pods с ошибкой didn't find available persistent volumes to bind.). Чтобы устранить эту взаимоблокировку, я определил один PersistentVolume для каждого узла (это может быть не идеально, но это сработало):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-data-node1
  labels:
    type: local
spec:
[…]
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - node1
person pedroapero    schedule 23.07.2020

arrow_upward
0
arrow_downward

Для меня проблема заключалась в несоответствии accessModes полей в PV и PVC. PVC запрашивал RWX/ReadWriteMany, а PV предлагал RWO/ReadWriteOnce.

person vladimirror    schedule 20.01.2021

arrow_upward
0
arrow_downward

waitforfirstconsumer-persistentvolumeclaim, т. е. POD, которому требуется этот PVC, не запланирован. описать стручки может дать больше подсказки. В моем случае узел не смог запланировать этот POD, поскольку ограничение на количество подов в узле было 110, а развертывание превышало его. Надеюсь, это поможет быстрее определить проблему. увеличил лимит pod, перезапуск kubelet в узле решает эту проблему.

person TheFixer    schedule 14.06.2021

arrow_upward
0
arrow_downward

В моем случае у меня было claimRef без указанного пространства имен.
Правильный синтаксис:

  claimRef:
    namespace: default
    name: my-claim

StatefulSet также мешал инициализации, мне пришлось заменить его развертыванием
Это была головная боль f5g

person Kiruahxh    schedule 23.06.2021