Могу ли я использовать локальные твердотельные накопители в GKE для быстрого временного хранения в модуле?

Question

У нас есть приложение, развернутое в GKE, для которого было бы полезно иметь быстрое временное хранилище на диске.

Функция локального SSD в GKE практически идеальна, однако мы имеем несколько реплик podв идеале нравится поддерживать несколько модулей на одном узле.Установка локального SSD с использованием hostPath делает это трудным.

В этом вопросе 2016 SO упоминается идея установки emptyDir s на локальном SSD, что было бы идеально, но я все еще понимаюне вариант.

Существует ветка списка рассылки 2017 с той же идеей, но ответ все еще не был положительным.

Документы GCPдля локальных твердотельных накопителей были недавно обновлены, чтобы описать их использование через абстракцию PersistentVolume, что звучит многообещающе.Могу ли я использовать это для достижения того, что мне нужно?

Примеры показывают, как монтировать полный локальный SSD как PersistentVolume, когда я предпочитаю использовать его изолированную часть для каждого модуля.Нам также не нужно, чтобы данные были постоянными - после удаления модуля мы также будем рады удалению данных.

Answer 1

В Kubernetes 1.11 добавлена ​​альфа-функция, называемая Поддержка нисходящего API в томе subPath , которая позволяет устанавливать подпути volumeMount с помощью нисходящего API.

Я проверил это, создав альфа-версию GKE 1.11кластер:

gcloud container clusters create jh-test --enable-kubernetes-alpha
  --zone=asia-southeast1-a --cluster-version=1.11.3-gke.18
  --local-ssd-count=1 --machine-type=n1-standard-2 --num-nodes=2
  --image-type=cos --disk-type=pd-ssd --disk-size=20Gi
  --no-enable-basic-auth --no-issue-client-certificate
  --no-enable-autoupgrade --no-enable-autorepair

Затем я создал развертывание с двумя репликами со следующей конфигурацией:

      env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
      volumeMounts:
        - name: scratch-space
          mountPath: /tmp/scratch
          subPath: $(POD_NAME)
  volumes:
    - name: scratch-space
      hostPath:
        path: "/mnt/disks/ssd0"

Если я kubectl exec 'd в каждом модуле, у меня было /tmp/scratchкаталог, который был изолированным и очень производительным.

Если я подключу SSHd к хосту, я смогу увидеть каталог для каждого модуля:

$ ls -l /mnt/disks/ssd0/
drwx--x--x 14 root root 4096 Dec  1 01:49 foo-6dc57cb589-nwbjw
drwx--x--x 14 root root 4096 Dec  1 01:50 foo-857656f4-dzzzl

Я также попытался применить развертывание кАльфа GKE 1.11 кластер, но содержимое SSD в итоге выглядело так:

$ ls -l /mnt/disks/ssd0/
drwxr-xr-x 2 root root 4096 Dec  1 04:51 '$(POD_NAME)'

К сожалению, нереально выполнить нашу рабочую нагрузку на альфа-кластер, поэтому это пока не прагматичное решение для нас.Нам придется подождать, пока эта функция достигнет бета-версии и станет доступной в стандартных кластерах GKE.Кажется, он медленно прогрессирует , хотя API , вероятно, изменится незначительно .

Для kubernetes 1.14 синтаксис для volumeMounts был изменен для использования новогоsubPathExpr поле.Функция остается только в альфа-формате:

      env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
      volumeMounts:
        - name: scratch-space
          mountPath: /tmp/scratch
          subPathExpr: $(POD_NAME)
  volumes:
    - name: scratch-space
      hostPath:
        path: "/mnt/disks/ssd0"