Kubernetes: как управлять данными с несколькими репликами?
В настоящее время я изучаю Kubernetes, и я застрял в том, как справиться со следующей ситуацией:
У меня есть приложение Spring Boot, которое обрабатывает файлы (фотографии, pdf и т. д.), загруженные пользователями, пользователи также могут загружать эти файлы. Это приложение также создает журналы, которые распределены по 6 различным файлам. Чтобы упростить себе жизнь, я решил создать корневой каталог, содержащий 2 подкаталога (1 каталог для данных пользователей и 1 для журналов), поэтому приложение работает только с 1 каталогом (appData)
.appData
|__ usersData
|__ logsFile
Я хотел бы использовать GKE (Google Kubernetes Engine) для развертывания этого приложения, но у меня есть следующие проблемы:
- Как обрабатывать несколько реплик, которые будут одновременно читать/записывать данные и журналы в каталоге
appData? - Что касается журналов, возможно ли, чтобы несколько подов записывали в один и тот же файл?
- Скажем, у нас есть 3 реплики (Pod-A, Pod-B и Pod-C), если пользователь A загружает файл, обработанный Pod-B, как Pod-A и Pod-C обнаружат этот файл, если тот же пользователь запросит его позже. файл?
- Должна ли каждая реплика иметь свой том? (Я хотел бы избежать этой ситуации, которая, кажется, имеет место при использовании StatefulSet)
- Должен ли я иметь только одну реплику? (использование Kubernetes в этом случае будет бесполезно)
Те же вопросы о репликах базы данных.
Я использую PostgreSQL и у меня те же вопросы. Если у нас есть несколько реплик, поскольку запросы случайным образом отправляются репликам, как быть уверенным, что запрос данных вернет результат?
Я знаю, что там много вопросов. Большое спасибо за ваши разъяснения.
Ответы 2
Вы можете использовать постоянный том с помощью NFS в GKE (Google Kubernetes Engine) для обмена файлами между модулями. https://cloud.google.com/filestore/docs/accessing-fileshares
А что с базой данных?
Вам нужно использовать постоянный том для обмена состоянием между вашими модулями. Также для базы данных вы можете использовать архитектуру ведущий-ведомый. Для базы данных см. kubernetes.io/docs/tasks/run-application/…
Я бы сделал два отдельных решения для журналов и для общих файлов.
Для журналов посмотрите на агрегатор журналов, такой как fluentd.
Для общей файловой системы вам нужен NFS. Взгляните на этот пример: https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs. NFS будет использовать постоянный том из GKE, Azure или AWS. Само по себе это не зависит от облака, но единственное, что вы меняете, — это ваш поставщик, если вы хотите работать в другом облаке.
Спасибо большое посмотрю и отпишусь
О базе данных Я буду использовать экземпляр Cloud SQL, чтобы быстро начать работу. Позже я перейду на архитектуру master/stave, когда пойму, как настроить такую архитектуру в Kubernetes.
Спасибо за это предложение, но ссылка предполагает, что мы создали экземпляр FileStore. Я бы хотел, чтобы приложение было максимально независимым от облачного провайдера.