Как распределить хранилище между контейнерами Кубернетес?

Ответ 1

Немного поздно ответить на этот вопрос, но из моего опыта до сих пор Kubernetes/MSA проблема здесь больше в вашем шаблоне проектирования. Одним из основных шаблонов проектирования, которые часто возникают в MSA, является надлежащее инкапсулирование ваших услуг, которое также включает в себя его данные.

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

Я предполагаю, что Google придерживается такого же мнения, и именно поэтому Kubernetes настроен таким образом.

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

Ответ 2

NFS - это встроенный плагин тома и поддерживает множественные писатели. Нет никаких специальных вариантов сборки, чтобы заставить NFS работать в Kube.

Я работаю в Red Hat на Kubernetes, ориентируясь главным образом на хранилище.

Ответ 3

Прежде всего. Kubernetes не имеет встроенной функциональности для совместного использования хранилища между хостами. Есть несколько вариантов ниже. Но сначала, как разделить хранилище, если у вас уже есть настроенные тома.

Чтобы разделить том между несколькими модулями, вам нужно создать PVC с режимом доступа ReadWriteMany

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
    name: my-pvc
spec:
    accessModes:
      - ReadWriteMany
    storageClassName: myvolume
    resources:
        requests:
            storage: 1Gi

После этого вы можете смонтировать его на несколько модулей:

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app1
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'

Конечно, постоянный том должен быть доступен через сеть. В противном случае вам нужно убедиться, что все модули запланированы для узла с этим томом.

Существует несколько типов томов, которые подходят для этого и не привязаны к какому-либо облачному провайдеру:

• NFS
• RBD (Ceph Block Device)
• CephFS
• GlusterFS
• Объемы Portworx

Конечно, чтобы использовать том, вам нужно его сначала. То есть, если вы хотите использовать NFS, вам нужно настроить NFS на всех узлах в кластере K8s. Если вы хотите использовать Ceph, вам нужно настроить кластер Ceph и т.д.

Единственный тип тома, который поддерживает Kubernetes из коробки - это Portworks. В есть инструкция по настройке в GKE.

Для настройки кластера Ceph в K8s был разработан проект под названием Rook.

Но это все излишне, если вы просто хотите, чтобы папка с одного узла была доступна на другом узле. В этом случае просто настройте NFS-сервер. Это не будет сложнее, чем предоставление других типов томов, и потребляет гораздо меньше ресурсов процессора/памяти/диска.

Ответ 4

Обновление: лучший выбор, вероятно, Cloud Filestore, управляемая система NFS. Это дает вам полный произвольный доступ на чтение/запись к файлам, в отличие от GCS, который поддерживает только загрузку/выгрузку. Смотрите документы здесь.

Оригинал: вы пробовали Google Cloud Storage? Возможно, вы даже сможете использовать адаптер FUSE, чтобы отобразить его как сетевой диск.

Ответ 5

Если это журналы, которые вы хотите записать на диск, я предлагаю вам посмотреть logspout https://github.com/gliderlabs/logspout. Это будет собирать каждый журнал регистрации, а затем вы можете использовать довольно новую службу регистрации Google облачных плат, в которой используется fluentd. Таким образом, все журналы из каждого контейнера собираются в одном месте.

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

ИЗМЕНИТЬ

Для обмена файлами между контейнерами я рекомендую монтировать накопитель облачных хранилищ Google для каждого node в вашем кластере kubernetes, а затем установить его как тома в каждый модуль, который монтируется в этот смонтированный каталог на node, а не прямо на привод. Устанавливать его для каждого node хорошо, потому что стручки не запускаются на определенных узлах, поэтому лучше всего централизовать его в этом случае.

Ответ 6

Вы смотрели на кубернете Volumes? Вероятно, вы ищете создание gcePersistentDisk

Громкость gcePersistentDisk монтирует Google Compute Engine (GCE) Постоянный диск в ваш контейнер. В отличие от emptyDir, который стирается, когда Pod удаляется, содержимое PD сохраняется и объем просто размонтирован. Это означает, что PD может быть предварительно заполнен данными, и что данные могут быть "переданы" между контейнерами. Важно: вы должны создать PD, используя gcloud или API или интерфейс GCE, прежде чем вы сможете его использовать Существуют некоторые ограничения при использовании gcePersistentDisk: узлы на которых запущены контейнеры, должны быть виртуальные машины GCE, эти виртуальные машины должны находиться в тот же проект и зона GCE, что и функция PD A PD, заключается в том, что они могут монтироваться только для чтения несколькими потребителями одновременно. Эта означает, что вы можете предварительно заполнить PD вашим набором данных, а затем выполнить это параллельно с таким количеством стручков, сколько вам нужно. К сожалению, PD могут устанавливается только одним потребителем в режиме чтения-записи - нет допускаются одновременные авторы. Использование PD на стручке, контролируемой ReplicationController завершится с ошибкой, если PD не доступен только для чтения или количество копий равно 0 или 1.

Чтобы поддерживать несколько записей из разных контейнеров, вам, вероятно, понадобится создать один мудрый блок, который предоставляет услугу типа бережливости или сокета, которая предоставляет методы readFromDisk и WriteToDisk.

Ответ 7

Google недавно выпустила облачное хранилище файлов с учебным пособием здесь: https://cloud.google.com/filestore/docs/accessing-fileshares

Может быть хорошей альтернативой облачным хранилищам/корзинам для некоторых сценариев.

Ответ 8

@Marco - в связи с вопросом, связанным с Maven, мой совет будет состоять в том, чтобы перестать рассматривать это как проблему централизованного хранения и, возможно, думать об этом как о проблеме обслуживания.

Я использовал репозитории Maven в HTTP в прошлом (только для чтения). Я просто создаю репозиторий Maven и выставляю его поверх Apache/Nginx в своем собственном контейнере-докере с тем, что когда-либо выделенное хранилище вам нужно только для этого модуля, а затем используйте сервисное обнаружение, чтобы связать его с вашим приложением и системами сборки.

Ответ 9

То, что вы пытаетесь сделать, противоположно назначению kubernetes, так как каждый из модулей наиболее инкапсулирован, вам следует поискать другие варианты хранения:

1. Blobs (изображения, видео, аудио), вы должны использовать облачное хранилище
2. Для журналов вы должны использовать стекдрайвер
3. Другие мудрый вы должны BigQuery датастор Bigtable SQL гаечного ключа

У Google есть постоянный диск, который может достичь того, что вы пытаетесь сделать, но, как я уже сказал, вам лучше выбрать другие варианты Даже на диаграмме Google не рекомендуется использовать постоянный диск