Комментарии 5
То есть вся статья свелась к тому, что взяли кем-то написанное расширение для кубика и используете? Круто, надо поучиться у Вас говорить много и ни о чем, полезный навык когда хочешь что-то продать.
Привет, спасибо за комментрий! Очень жаль, что статья показалась для Вас поверхностной.
В статье старался раскрыть опыт именно переезда и использование Flink в условиях K8s. Flink k8s operator - это общее решение, которое поддерживается Apache вместе с самим Flink.
Техническая сложность и неопределенность берется именно в том, чтобы перейти от схемы развертывания Flink-кластеров на обычных нодах и управления ими, к архитектуре работающей в экосистеме K8s, что само по себе дает значительные преимущества (см. в статье), но и создает достаточно много челенджей, именно поэтому не каждая команда решается на такой апгрейд. В Avito у нас получилось построить такую архитектуру enterprise-уровня, что и описывается в данной статье, поэтому решили поделится опытом и вдохновить других.
Будет круто, если добавишь информации:
1) Где храните описание самих flink-job связанных с конкретной обработкой чего-то:
а) все джобы в одном репозитории;
б) под каждую джобу свой репозиторий;
в) джобы лежат где-то рядом с кодом сервисов, отвечающих за функциональность, которую джоба обрабатывает?
2) Что конкретно делают flink-job-ы: откуда берут данные, куда записывают? Если kafka->flink->kafka - нет ли проблемы, что на первом запуске нужно получить какие-то данные из истории событий, которых в kafka уже нет из-за retention?
3) Получается, в версии с K8S все кластера работают в режиме Application или режим Session всё-еще используете?
4) Сколько времени внедрение заняло, сколько человек над ним работало?
Привет! Спасибо за классные вопросы.
1) Используем моно-репо для job и отдельный репо для соответствующих Helm-чартов. Но тут вопрос вкуса, я считаю, что исходить надо из удобства Data инженеров, которые пишут Flink job ы, а также из архитектуры CI/CD, чтобы максимально сократить TTM, снизить риск ошибок, а также уменьшить кол-во мест, где руками нужно вносить правки при изменениях в коде.
2) Такая проблема может возникнуть, чтобы минимизировать риски необходимо:
a) Правильно высчитывать размеры топиков и их ретеншн, договариваться и соблюдать целевой SLA на стороне Kafka.
б) Создавать архитектуру Flink, которая способна держать стабильный uptime job-ов. Переезд в k8s как раз значительно повысил стабильность Flink-кластеров, а также позволил куда проще ими управлять, благодаря чему значительно снизился риск возникновения описанного Вами кейса.
3) 90% кластеров Flink в k8s работают в режими application. Есть исключения (10%), которые запускаем в session, но обычно это что-то тестовое.
4) Внедрение заняло довольно большое кол-во времени (около года), над ним работал в основном один SRE инженер и команда Data инженеров. На тот момент в индустрии с таким переходом не так много было описанного опыта, поэтому многие челенджы решали сами, при наличие требований к стабильности и перфомансу. К тому же нужно было поднимать всю экосистему k8s с нуля.
Если Flink Cluster (Taks managers) растянуты на несколько ЦОДов, то таски перебрасываются между таск менеджерами в разных ЦОДах и на больших объемах это абсолютно хаотичный огромный трафик, причем с минимальной эффективностью, т.к., как правило, сами таски небольшие, но их много.
Запуск такой нагрузки на распределенный k8s-кластер наверное реально обоснован таким оверхедом?
Kafka, из которой вы читаете скорее всего также должна быть размазана по ЦОДам.
В таком случае сеть между этими ЦОДами должна быть по пропускной способности аналогичной сети внутри ЦОДа по пропускной способности и latency.
Хорошо, когда есть инфра с такими безграничными возможностями :)
Flink Kubernetes operator: опыт построения стриминговой Big Data платформы