Обработка заданий Redis KUE в нескольких подах / экземплярах Kubernetes

Я использую Sails.js для API, который я развертываю из Dockerfile в кластере Google Cloud kubernetes и масштабирую рабочую нагрузку с помощью 3-5 модулей. API предоставляет конечные точки для загрузки отдельных файлов изображений и zip-файлов большего размера, которые я извлекаю напрямую в текущий модуль / экземпляр API.

И отдельные файлы изображений, и извлеченное содержимое архива (100-1000 файлов, всего 15-85 МБ содержимого), я должен загрузить в различные сегменты хранилища. Здесь в игру вступает Redis Kue. Чтобы убедиться, что API не блокирует запрос на загрузку слишком долго, я создаю отложенные задания kue для перемещения всех загруженных файлов и папок в сегменты хранилища или цепочки заданий и сначала создаю эскизы с помощью ImageMagick.

Все это может занять некоторое время, в зависимости от текущей загруженности кластера, иногда больше, а иногда меньше.

Все это прекрасно работает с одним экземпляром, но внутри кластера - это совсем другая история. Поскольку экземпляр kubernetes для API может изменяться от запроса к запросу, загрузки могут попадать в экземпляр A, но задание для файлов обрабатывается и обрабатывается экземпляром B (Рабочий, так же как и сам API, работают в одном экземпляре!), У которого может не быть доступных загрузок, что приводит к сбою задания.

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

Я пробовал следующее:

Поскольку имя текущего модуля доступно через переменную env HOSTNAME, я сохраняю HOSTNAME со всеми заданиями kue и проверяю внутри рабочего, если HOSTNAME < / em> из заданий совпадает с HOSTNAME текущей среды и позволяет обрабатывать задания только в том случае, если оба HOSTNAME совпадают.

Загрузки должны быть доступны как можно скорее; почему я не могу добавить задержку задания в несколько минут и надеюсь, что к тому времени, когда задание будет обработано, Google синхронизирует свои модули.

Ожидающие задания, которые не соответствуют HOSTNAME, я возвращаю в очередь и добавляю к ней задержку.

Я хочу иметь очередь, которая не должна заботиться об именах хостов и условных проверках для успешной обработки своих заданий в кластере, подобном моему.


person bulletinmybeard    schedule 19.04.2019    source источник


Ответы (1)


для этого «у которого может не быть доступных загрузок, что приведет к неудачной работе», не могли бы вы подумать об использовании «Постоянные тома".

В этом случае ваши рабочие места могут работать независимо, ища извлеченный архивный контент в общее хранилище.

Надеюсь на эту помощь. Пожалуйста, поделитесь своими выводами.

person Mark    schedule 23.05.2019