Как разделить реализацию синхронизации приложений и данных в Kubernetes? - PullRequest
0 голосов
/ 26 февраля 2019

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

Здесьхарактеристики данных приложения и их использование:

  • Данные не часто обновляются , но читаются очень часто приложением
  • Данные не являются базой данных, это набор файловых объектов размером от 100 МБ до 4 ГБ, которые изначально хранятся в облачном хранилище
  • Данные, хранящиеся в облачном хранилище, служат как единое целоеисточник правды для данных приложения
  • Приложение будет только читать из данных.Процесс обновления данных в облачном хранилище - это внешний процесс, выходящий за рамки приложения.

Таким образом, здесь мы заинтересованы в синхронизации данных в облачном хранилище с томом в развертывании Kubernetes.Как лучше всего достичь этой цели в Кубернетесе?

У меня есть несколько вариантов:

  1. Использование одного контейнера приложения в одном развертывании, в котором приложение также будетвключает логику загрузки и обновления данных, которая переносит данные из облачного хранилища в контейнер -> просто, но тесно связана с реализацией чтения-записи хранилища

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

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

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

    • внешний процесс, который записывает на постоянный диск (не уверенкак это сделать с облачным хранилищем / файловыми объектами, нужно найти способ синхронизации gcs с постоянным диском)
    • один контейнер для службы приложений, который читает с подключенного тома
  5. Использование монтируемых предохранителей

    • внешний процесс, который записывает в облачное хранилище
    • контейнер, использующий монтируемые предохранители

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

1 Ответ

0 голосов
/ 26 февраля 2019

Да.3. является наиболее распространенным вариантом, но убедитесь, что вы используете initContainer для копирования данных из облачного хранилища на локальный том.Этот локальный том может быть любым из типов , поддерживаемых Kubernetes.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...