Привет всем. скажите как в джобе сделать запрос ко всем

подам скрытым за сервисом? (ответ от подов не важен - но нужно дождаться окончания всех запросов только)

?

// это кронджоба - и окончания нужно дожаться просто чтобы не стартовался второй инстанс джобы

Запрос выглядит странно на мой взгляд. Но это либо headless service - там возвращаются все адреса подов. Либо делать запрос в куб апи из джобы и получать сервис со списком эндпоинтов

а почему странно?

Чтобы не стартовал второй инстанс джобы есть механизмы проще

Куб достаточно динамичный. Точнее динамично то, что туда задеплоено. И если кронджоба что-то делает с подами или что-то делает с другими подами на основании получения инфы из этих всех подов, то при автоскейлинге или просто ручном скейлинге что-то может сломаться. Без деталей сложно сказать точно, но я бы сказал, что такая архитектура выглядит хлипко.

понял, спасибо думаю, что там у человека вряд ли важна такая динамика, что в момент старта джобы может измениться набор подов, но это мои догадки в остальном - вроде норм подход же?

Я бы искал другие пути реализации. Но понятно, что костыли иногда делать приходится. Если сделаешь что-то хлипкое, то потом паттерн будут использовать не по тому назначению, по которому ты его сделал. Т.е. раньше работало норм, а потом не норм. А разработка не будет понимать почему так получилось.

у меня пока с джобами в кубере нет любви; джобы поднимаются как отдельные поды (отработал-и-умер), я не нашёл варианта как джобой поднимать сайдкарами контейнеры в существующих подах деплоймента) с той же логикой отработал-и-умер

Джобой поднимать что?

Извращенец

абстрагируйс до "требуется по расписанию поднимать сайдкарном контейнер в подах деплоймента"

Чушь придумал

мне нужно чтобы периодически получать обновления переводов. а вот внутри переводы храняться в файлах. nfs итп нет возхможности сейчас. да и медленно.. local вариант - но локализовно по нодам.. я и подумал что если будет кронджоба которая могла бы запросить все поды самим выполнить нужный функцонал - просто старт инициировать.. если несколько нод не сделают это в этот цикл - не критично - через некоторое время повториться

kubectl get ep service-name получаешь объект endpoints в котором есть все ип адреса подов и сами поды

а это можно. Ты можешь сайдкар в ephemeralContainers засунуть, дождаться когда выполнится, и удалить

Я про это и говорил 🤷‍♂️

сорян, не увидел. Тред пролистал быстро

а почему бы просто переводы не хранить в репе и не вшивать в образ при сборке? Зачем их отдельно?

снова не понимаю предложенную схему по крону стартует джоба, поднимающая не отдельный под, а сразу N эфемерных контейнеров присайдкаренных в поды нужного деплоймента?

ты же сказал что нужно выполнять в сайдкаре существующего пода, зачем отдельный под поднимать?

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

Меня триггерит выражение "поднять сайдкар внутри пода" :) Я согласен патчить существующие поды только адмишг хуком)

запускаешь job, в ней выполняется код, который в существующий в кластере pod, добовляет эфимерный контейнер можно даже тупо kubectl'ем

а, понял, т.е. сходить в кубеапи не, мне такое меньше нравится

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

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

но ваще я бы на твоем месте просто supercronic в сайдкар залил и всё

не тривиальная задача же: под джобы стартует эфемерку, а потом как-то ловит её статус завершения

статус по API будет доступен по идее. В status пода

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

в статусе пода есть статусы всех контейнеров