Почему спрашиваю - у нас датадантистов человек 20, и мы прям заморачивались чтоб даги прям в момент паковались и улетали. Людям очень понравилось

При том что до этого пайплайн занимал около 15 минут

@krasina15 расскажи пожалуйста как вы этого добились))

У нас их чуть больше и мы делали, чтобы каждая команда/человек были почти независимы, ибо важнее сделать изолированность для ДС, чем каждому соблюдать условие "сидим на этой версии либы"

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

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

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

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

А 200+ либ зависимостей вы не учитываете? 😬

А можно просто файлики с заменой закинуть по ssh 😂

Тоже довольно быстро, правда пока без тестов(

Если хотите время запуска пода - собирайте метрики с kubelet, учётка привилегированная нужна правда.
Щас подумываем чтобы это делать через sidecar контейнеры, но выглядит сложнее.

Вопрос был вообще не про это)))

тогда получается и ответ получился совсем не про то)))

Спасибо за адекватный фидбек. Именно из-за специфики с привилегиями в корп кубере у меня и возникли такие вопросы. Мониторинг самого аирфлоу позволяет  считать лаг между ожидаемым и фактическим стартом даграна (dagrun...delay), а время на поднятие подов в офиц доке аирфлоу рекомендуют через стрим некого Kubernetes watcher'а - может это и есть kubelet?  Не поможете полезной ссылкой по теме?
--
Насчёт sidecar контейнеров - а какие метрики с подов в этом случае появятся? Метрики жизни самого пода и его состояний?

Метрики приложения аирфлоу из подов разве  возможны? Или с подов как раз и будут метрики воркера и оператор саксесс /фейл?

Ну наверно можно и через watcher смотреть. У нас команда администрирующая куб дает нам сама эти метрики, чтоб не насоветовать ерунды, лучше спросите где-то еще)
С sidecar нам больше интересны cpu/memory метрики, их можно как вариант получать из cgroup (можно и из kubelet, но у нас там свои особенности).

Ну дефолтные метрики же вроде читаются из базы всегда, какая разница как у вас задачи в af запускаются.

Ок,спасибо за пояснения.
....
По дефолтным метрикам...
при использовании Kubernetes Executor часть аирфлоу метрик отсутствуют, к примеру ti_success,  ti_failed и ещё несколько. Потому и ищу обходные пути

Всем привет.
Подскажите пожалуйста причину или укажите на ссылку, почему gunicorn webserver-а рестартует worker-ов.
Я подозреваю, чтобы увидеть новые даги, но не могу нигде найти подтверждение

Точно не для парсинга дагов, есть такой параметр worker_refresh_batch_size https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#worker-refresh-batch-size, в зависимости от его значения, Airflow будет иногда грохать воркеров и поднимать новых. Зачем? Наверное, имеет смысл смотреть код. Но у них часто есть решения вида "если что-то деградирует – ребутай чаще"