Постоянная проблема с диском в Kubernetes GCP

Я работаю в Kubernetes в GCP, и у меня проблемы с томами и постоянными дисками.

Я использую Directus 7 (CMS Headless), который сохраняет большую часть своей информации в базе данных, кроме загружаемых файлов, эти файлы находятся в папке /var/www/html/public/uploads (проверено локально с помощью docker-compose и работает нормально), и именно эту папку я пытаюсь сохранить на постоянном диске.

Ошибки не возникает, но при перезапуске Kubernetes Pod загруженные изображения теряются (они не сохраняются на диске).

Это моя конфигурация:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: directus-pv
  namespace: default
spec:
  storageClassName: ""
  capacity:
    storage: 100G
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    pdName: directus-disk
    fsType: ext4

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: directus-pvc
  namespace: default
  labels:
    app: .....
spec:
  storageClassName: ""
  volumeName: directus-pv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100G

И в файле deploy.yaml:

    volumeMounts:
      - name: api-disk
        mountPath: /var/www/html/public/uploads
        readOnly: false

  volumes:
  - name: api-disk
    persistentVolumeClaim:
      claimName: directus-pvc

Спасибо за помощь


kubernetes google-cloud-platform docker persistent-storage directus
person pdsm    schedule 15.02.2019    source источник
comment
Пробовали ли вы использовать PVC для автоматического создания PV?   -  person cookiedough    schedule 16.02.2019
comment
Да, но тот же результат   -  person pdsm    schedule 18.02.2019
comment
не уверен, что это поможет, но я попробовал что-то подобное, и это сработало, разница была в том, что я удалил оператор readOnly: false и установил mountPath в /var/www/html, используя PVC для создания PV сам по себе. Не имеет смысла исправлять это, но попробуйте. Если это не сработает (что вполне вероятно), возможно, вам чего-то не хватает в кластере, возможно, тогда попробуйте это на новом кластере.   -  person cookiedough    schedule 19.02.2019
comment
Используете ли вы GKE или собственное решение на GCP?   -  person Nepomucen    schedule 21.02.2019

Ответы (2)


arrow_upward
0
arrow_downward

Удалите свойство пространства имен из манифеста pv и pvc. Это общие ресурсы в кластере. Также удалите свойство класса хранилища.

person P Ekambaram    schedule 16.02.2019

arrow_upward
0
arrow_downward

Я предполагаю, что ваш подготовленный вручную постоянный том directus-pv каким-то образом создается с помощью PersistentVolumeReclaimPolicy=*Переработать. Это единственная возможная причина, которая может привести к стиранию данных при каждом перезапуске POD.

Я не могу воспроизвести ваш случай с предоставленными файлами манифеста, но я попробовал следующий тест:

  1. Создать gcePersistentDisk
  2. Создать постоянный том
  3. Создать персистентволумеклайм
  4. Создайте ReplicaSet (реплики = 1), как этот

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: busybox-list-uploads
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: busybox-list-uploads
        version: "2"
    spec:
      containers:
        - image: busybox
          args: [/bin/sh, -c, 'sleep 9999' ]
          volumeMounts:
            - mountPath: /var/www/html/public/uploads
              name: api-disk
          name: busybox
      volumes:
      - name: api-disk
        persistentVolumeClaim:
          claimName: directus-pvc

  1. Запишите какой-нибудь файл в смонтированную папку /var/www/html/public/uploads
  2. Перезапустите POD (= убейте POD), изменив размер реплики до 0, а затем до 1.
  3. Список содержимого /var/www/html/public/uploads во вновь созданном POD

для i в busybox-list-uploads-dgfbc; do kubectl exec -it $i -- ls /var/www/html/public/uploads; Выполнено; потерянный + найденный picture_from_busybox-list-uploads-ng4t6.png

Как вы можете видеть, выходные данные ясно показывают, что данные сохраняются после перезапуска POD

* вы можете проверить это с помощью cmd: kubectl get pv/directus-pv -o yaml

person Nepomucen    schedule 21.02.2019