Как смонтировать постоянный том на Deployment / Pod, используя PersistentVolumeClaim?

Question

Я пытаюсь смонтировать постоянный том на модулях (через развертывание).

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - image: ...
        volumeMounts:
        - mountPath: /app/folder
          name: volume
      volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: volume-claim
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

Однако модуль остается в состоянии «ContainerCreating», и события показывают следующее сообщение об ошибке.

Unable to mount volumes for pod "podname": timeout expired waiting for volumes to attach or mount for pod "namespace"/"podname". list of unmounted volumes=[volume]. list of unattached volumes=[volume]

Я подтвердил, что заявка на постоянный том в порядке и связана с постоянным томом.

Что мне здесь не хватает?

Answer 1

Когда вы создаете PVC без указания PV или типа StorageClass в кластерах GKE, он возвращается к параметру по умолчанию:

• StorageClass: standard
• Provisioner: kubernetes.io/gce-pd
• Type: pd-standard

Ознакомьтесь с официальной документацией: Cloud.google.com: постоянные тома движка Kubernetes

Может возникнуть множество обстоятельств, которые могут привести к появлению сообщения об ошибке.

Поскольку неизвестно, сколько реплик находится в вашем развертывании, а также количество узлов и то, как планировались пакеты на этих узлах, я попытался воспроизвести вашу проблему, и я столкнулся с той же ошибкой, выполнив следующие действия (GKE кластер был создан заново для предотвращения любых других зависимостей, которые могут повлиять на поведение).

Шаги :

• Создание PV C
• Создать развертывание с помощью replicas > 1
• Проверить состояние модулей
• Дополнительные ссылки

Создать PV C

Ниже пример YAML определение PVC совпадает с вашим:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

После применения приведенного выше определения, пожалуйста, проверьте, успешно ли оно создано. Вы можете сделать это, используя следующие команды:

• $ kubectl get pvc volume-claim
• $ kubectl get pv
• $ kubectl describe pvc volume-claim
• $ kubectl get pvc volume-claim -o yaml

Создание развертывания с replicas > 1

Ниже приведен пример YAML определения развертывания с volumeMounts и replicas> 1:

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: ubuntu-deployment
spec:
  selector:
    matchLabels:
      app: ubuntu
  replicas: 10 # amount of pods must be > 1
  template:
    metadata:
      labels:
        app: ubuntu
    spec:
      containers:
      - name: ubuntu
        image: ubuntu
        command:
        - sleep
        - "infinity"
        volumeMounts:
        - mountPath: /app/folder
          name: volume
      volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: volume-claim

Apply это и подождите некоторое время.

Проверка состояния модулей

Вы можете проверить состояние модулей с помощью следующей команды:

$ kubectl get pods -o wide

Вывод вышеуказанной команды:

NAME                      READY   STATUS              RESTARTS   AGE     IP            NODE                              
ubuntu-deployment-2q64z   0/1     ContainerCreating   0          4m27s   <none>        gke-node-1  
ubuntu-deployment-4tjp2   1/1     Running             0          4m27s   10.56.1.14    gke-node-2   
ubuntu-deployment-5tn8x   0/1     ContainerCreating   0          4m27s   <none>        gke-node-1   
ubuntu-deployment-5tn9m   0/1     ContainerCreating   0          4m27s   <none>        gke-node-3  
ubuntu-deployment-6vkwf   0/1     ContainerCreating   0          4m27s   <none>        gke-node-1  
ubuntu-deployment-9p45q   1/1     Running             0          4m27s   10.56.1.12    gke-node-2  
ubuntu-deployment-lfh7g   0/1     ContainerCreating   0          4m27s   <none>        gke-node-3  
ubuntu-deployment-qxwmq   1/1     Running             0          4m27s   10.56.1.13    gke-node-2 
ubuntu-deployment-r7k2k   0/1     ContainerCreating   0          4m27s   <none>        gke-node-3   
ubuntu-deployment-rnr72   0/1     ContainerCreating   0          4m27s   <none>        gke-node-3

Посмотрите на вывод выше:

• 3 контейнера находятся в Running состоянии
• 7 модулей находятся в ContainerCreating состоянии

Все блоки Running расположены на одном и том же gke-node-2

Более подробную информацию о том, почему блоки находятся в состоянии ContainerCreating, можно получить:

$ kubectl describe pod NAME_OF_POD_WITH_CC_STATE

Часть Events в приведенной выше команде показывает:

Events:
  Type     Reason              Age                From                                             Message
  ----     ------              ----               ----                                             -------
  Normal   Scheduled           14m                default-scheduler                                Successfully assigned default/ubuntu-deployment-2q64z to gke-node-1
  Warning  FailedAttachVolume  14m                attachdetach-controller                          Multi-Attach error for volume "pvc-7d756147-6434-11ea-a666-42010a9c0058" Volume is already used by pod(s) ubuntu-deployment-qxwmq, ubuntu-deployment-9p45q, ubuntu-deployment-4tjp2
  Warning  FailedMount         92s (x6 over 12m)  kubelet, gke-node-1  Unable to mount volumes for pod "ubuntu-deployment-2q64z_default(9dc28e95-6434-11ea-a666-42010a9c0058)": timeout expired waiting for volumes to attach or mount for pod "default"/"ubuntu-deployment-2q64z". list of unmounted volumes=[volume]. list of unattached volumes=[volume default-token-dnvnj]

Модуль не может перейти в состояние ContainerCreating из-за неудачной установки volume. Упомянутый volume уже используется другими модулями в другом узле.

ReadWriteOnce: Том можно монтировать как чтение-запись одним узлом.

Дополнительные ссылки

Пожалуйста, примите посмотрите на: Cloud.google.com: режимы доступа к постоянным томам .

Подробный ответ на топи c режима доступа: Stackoverflow.com: почему вы можете установить несколько режимов доступа на постоянном томе

Поскольку неизвестно, что вы пытаются достичь, пожалуйста, посмотрите на сравнение между Deployments и Statefulsets: Cloud.google.com: постоянный том: Deployments vs statefulsets .

Answer 2

Если вы делаете это в облачном провайдере, объект storageClass создаст соответствующий том для вашей заявки на постоянный том.

Если вы пытаетесь сделать это локально на мини-кубе или в кластере kubernetes с самоуправлением, вы необходимо вручную создать storageClass, который предоставит вам тома, или создать его вручную, как в этом примере:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Переменная hostPath будет монтировать эти данные в текущий узел pod.