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 в условиях K8s. Flink k8s operator - это общее решение, которое поддерживается Apache вместе с самим Flink.
Техническая сложность и неопределенность берется именно в том, чтобы перейти от схемы развертывания Flink-кластеров на обычных нодах и управления ими, к архитектуре работающей в экосистеме K8s, что само по себе дает значительные преимущества (см. в статье), но и создает достаточно много челенджей, именно поэтому не каждая команда решается на такой апгрейд. В Avito у нас получилось построить такую архитектуру enterprise-уровня, что и описывается в данной статье, поэтому решили поделится опытом и вдохновить других.
Привет! Спасибо за классные вопросы.
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 в условиях K8s. Flink k8s operator - это общее решение, которое поддерживается Apache вместе с самим Flink.
Техническая сложность и неопределенность берется именно в том, чтобы перейти от схемы развертывания Flink-кластеров на обычных нодах и управления ими, к архитектуре работающей в экосистеме K8s, что само по себе дает значительные преимущества (см. в статье), но и создает достаточно много челенджей, именно поэтому не каждая команда решается на такой апгрейд. В Avito у нас получилось построить такую архитектуру enterprise-уровня, что и описывается в данной статье, поэтому решили поделится опытом и вдохновить других.