Флинк кластер на ЭКС

Question

Я новичок во Флинке и Куберне. Я планирую создать потоковое задание flink для потоковой передачи данных из файловой системы в Kafka.

Имеет банку flink job, которая работает нормально (проверено локально). Сейчас я пытаюсь разместить эту работу в kubernetes и хотел бы использовать EKS в AWS.

. Я прочитал официальную документацию по flink по настройке кластера flink. https://ci.apache.org/projects/flink/flink-docs-release-1.5/ops/deployment/kubernetes.html

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

Мои вопросы: 1) Нет из двух вариантов: кластер заданий и кластер сеансов, поскольку задание является потоковым заданием и должно следить за файловой системой, а при появлении в нем любых новых файлов должно передаваться по назначению, могу ли я использовать кластер заданий в этом случае? Согласно документации, кластер заданий - это то, что выполняет задание и завершается после его завершения. Если задание имеет монитор в папке, оно когда-либо завершается?

2) У меня есть проект maven, который создает flink jar, Хотите узнать идеальный способ раскрутить кластер сеанса / задания, используя эту банку в производстве? каков нормальный процесс CI CD? Должен ли я сначала создать кластер сеансов и при необходимости отправлять задания? или раскрутить кластер заданий со встроенным кувшином?

Answer 1

Во-первых, вы указали ссылку на Flink 1.5. Если вы запускаете fre sh, я бы порекомендовал использовать Flink 1.9 или предстоящий 1.10.

. Для ваших вопросов:

1) Работа с файловым монитором никогда не прекращается. Он не может знать, когда больше нет файлов, поэтому вы должны отменить его вручную. Кластер заданий подходит для этого.

2) На этот вопрос нет четкого ответа, и он также не указан Flink c. У каждого свое решение с разными недостатками.

Я бы хотел полуавтоматический подход c, где все автоматизировано c, но вам нужно явно нажать кнопку развертывания (а не просто git pu sh). Часто эти конвейеры CI / CD сначала развертываются на тестовом кластере и проводят тест дыма, прежде чем разрешить развертывание в рабочей среде.

Если вы полностью свободны sh, вы можете проверить AWS codedeploy . Тем не менее, я получил хороший опыт работы с Gitlab и AWS runner.

Обычный процесс будет выглядеть примерно так:

• build
• интеграция / e2e тесты на сборочной машине (dockerized)
• развертывание в тестовом кластере / preprod cluster
• запуск тестов дыма
• развертывание на prod

Я также видел процессы, которые go быстро работают на prod и тратят время на улучшение мониторинга и быстрый откат вместо кластера preprod и тесты дыма. Обычно это подходит для бизнес-некритических процессов и того, насколько дорогой является переработка.