Блог

В Kubernetes вы явно указываете ограничения ресурсов для контейнера. При запуске соединителя Kafka вы запрашиваете максимальное количество задач, но как рабочий кластер connect узнает, как распределить нагрузку? Считает ли он задачи равными? Использует ли он внутренние показатели?

В документах Apache Kafka и документах confluent явно не указано, за исключением того, что Confluent рекомендует следующее, что указывает на то, что работники connect не имеют управления ресурсами:

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

https://docs.confluent.io/3.1.2/connect/userguide.html#connect-standalone-v-distributed

Кроме того, для развертывания кластера, по-видимому, требуется внешний менеджер ресурсов для обработки отработки отказа работников.

Работники Kafka Connect могут быть развернуты несколькими способами, каждый со своими преимуществами. Рабочие хорошо подходят для запуска в контейнерах в управляемых средах, таких как YARN, Mesos или Docker Swarm, поскольку все состояния хранятся в Kafka, что делает сами локальные процессы без состояния. Мы предоставляем изображения Docker, и документация для начала работы с этими изображениями находится здесь. По своей конструкции Kafka Connect не обрабатывает автоматически перезапуск или масштабирование рабочих, что означает, что ваши существующие решения для кластеризации могут продолжать использоваться прозрачно.

как рабочий кластер connect узнает, как распределить нагрузку

Каждый соединитель может выбрать разделение своей работы на задачи (например, прием нескольких таблиц из одной базы данных может выполняться параллельно, и поэтому одна таблица будет выполняться одной задачей), вплоть до tasks.max установленного предела.

Kafka Connect распределяет эти задачи по доступным работникам таким образом, чтобы они были равномерно распределены (в зависимости от количества задач).

Протокол перебалансировки изменен в выпуске 2.3 Apache Kafka как часть KIP-415, подробности есть в KIP и здесь . В двух словах, при постепенном совместном перебалансировании Kafka Connect распределяет задачи поровну, начиная с наименее загруженных рабочих, в конечном итоге включая больше рабочих, пока нагрузка выравнивается.

Кроме того, для развертывания кластера, по-видимому, требуется внешний менеджер ресурсов для обработки отработки отказа работников.

Чтобы было понятно — переход на другой ресурс задач выполняется автоматически с помощью Kafka Connect, и, как вы говорите, переход на другой ресурс работников будет управляться извне.