Комментарии 3
Здравствуйте,
Сспасибо за статью. Я не совсем понял как вы решаете вопрос установки новых Python модулей. Через обновление имеджей или нашли более удобный способ?
Вы не рассказали про опыт. Кроме одного патча, который вы подменяете в Airflow, всё стандартно. Как насчёт проблем?
1) Поды падают во время выполнения, перерабатывая текст в csv мегов на 20 (OOMKilled). Разработчик клянётся, что там нечему жрать память. Поднимаю память, запуская процесс снова и снова. На трёх гигах ОЗУ Pandas наконец-то начинает шевелиться и отрабатывает. Наказаний за такой жрущий код нет, подразумевается "если такой умный - покажи, как надо". Хотя перерабатывается в CSV по сути pg dump, надо всего лишь заглянуть в доку и написать copy to stdout format CSV, например.
2) Некоторые операторы - самописные и декларация ресурсов в DAG не делает ничего, внутри них просто нет кода для обработки этого, но при этом внутри шага с оператором запускается тот же Pandas. Стискиваю зубы и поднимаю в worker template лимиты до 2ГБ вообще для всех.
3) Поды начинают падать до начала выполнения, но пишут лог в s3. Оказывается, запускать сразу много подов в полночь чревато, они начинают толпиться и некоторые умирают в давке, потому что узлы не могут сразу принять все поды, когда они требуют по 2ГБ на каждую задачу внутри DAG. Поднимаю worker_pods_pending_timeout до трёх часов, чтобы когда-нибудь да выполнились.
4) Поды вроде бы падают неизвестно когда, но ничего не пишут в s3. Airflow отображает "falling back to local log" и 404 - пода уже нет. О, это самый интересный случай, нетривиальный.
Стал собирать вывод подов в лог каждую минуту, посмотреть на статус. OutOfMemory. Не OOMKilled, а OutOfMemory. Оказывается, ошибка характерна для k8s 1.22, и это наша версия, обновить нельзя, legacy на последнем издыхании, съезжать тоже - свои причины. За неделю удалось уговорить проверить идею не запускать все поды в одну секунду. Помогло.
5) Поды падают с ошибкой upstream_failed. Оказалось, что если родительская задача падает, то в k8s executor следующая задача прекращает свою работу, когда срабатывает worker_pods_pending_timeout для неё, потому что момент начала работы (видимо) начинается с ожидания успешного выполнения родительской задачи.
https://github.com/apache/airflow/discussions/18395
https://stackoverflow.com/questions/73852012/airflow-task-improperly-has-an-upstream-failed-status-after-previous-task-succ
Но тут я не уверен, самый неисследованный случай, который просто перестал происходить, когда разобрались с историями 3 и 4.
Съел я на нём уже пуд соли, очень хочу обратно на Celery Executor на ВМ. Там и памяти завались, и процессы запускаются без контейнеров и вышеперечисленных органичений. А на бумаге хорошо, да.
Наш опыт эксплуатации Airflow в Kubernetes