Конфигурация сервера Kafka - слушатели против рекламируемых .listeners

Ответ 1

Поскольку я пока не могу комментировать, я опубликую это как "ответ", добавив к ответу M.Situations.

В том же документе, на который он ссылается, есть эта реклама, о которой слушатель использует клиент KAFKA (https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+ Внешний + трафик):

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

Это важно, поскольку в зависимости от того, какой URL вы используете в своей конфигурации bootstrap.servers, это будет URL *, который получит клиент, если он будет отображен в advertised.listeners (не знаю, каково поведение, если прослушиватель не существует).

Также обратите внимание на это:

Исключение составляют потребители на основе ZooKeeper. Эти потребители получают информацию о регистрации брокера непосредственно из ZooKeeper и выбирают первого прослушивателя с PLAINTEXT в качестве протокола безопасности (единственный протокол безопасности, который они поддерживают).

В качестве примера конфигурации брокера (для всех брокеров в кластере):

advertised.listeners = ВНЕШНЕЕ://XXXXX.compute-1.amazonaws.com: 9990, ВНУТРЕННЯЯ://ip-XXXXX.ec2.internal: 9993

inter.broker.listener.name = ВНУТРЕННИЙ

listener.security.protocol.map = ВНЕШНЕЕ: SSL, ВНУТРЕННЯЯ: PLAINTEXT

Если для подключения клиент использует XXXXX.compute-1.amazonaws.com:9990, выборка метаданных перейдет к этому посреднику. Однако возвращаемый URL-адрес для использования с координатором группы или руководителем может быть 123.compute-1.amazonaws.com:9990* (другой компьютер!). Это означает, что сопоставление выполняется по имени прослушивателя, как объявлено KIP-103, независимо от фактического URL (узла).

Поскольку карта протокола EXTERNAL - это SSL, это заставит вас использовать хранилище ключей SSL для подключения.

Если, с другой стороны, вы находитесь в AWS, скажем, вы можете выполнить ip-XXXXX.ec2.internal: 9993, и соответствующее соединение будет открытым текстом в соответствии с картой протокола.

Это особенно необходимо в IaaS, где в моем случае брокеры и потребители живут на AWS, тогда как мой продюсер живет на клиентском сайте, поэтому ему нужны разные протоколы безопасности и прослушиватели.

РЕДАКТИРОВАТЬ: Кроме того, добавить входящие правила теперь намного проще, поскольку у вас разные порты для разных клиентов (брокеров, производителей, потребителей).

Ответ 2

listeners - это то, что брокер будет использовать для создания серверных сокетов.

advertised.listeners - это то, что клиенты будут использовать для подключения к брокерам.

Эти две настройки могут отличаться, если у вас есть "сложная" настройка сети (с такими вещами, как публичные и частные подсети и маршрутизация между ними). ​​

Ответ 3

По этой ссылке: https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic

В течение цикла выпуска 0.9.0.0 была введена поддержка нескольких слушателей для каждого брокера. Каждый слушатель связан с протоколом безопасности, ip/host и портом. В сочетании с механизмом рекламируемых прослушивателей существует значительная гибкость с одним ограничением: не более одного прослушивателя на протокол безопасности в каждой из двух конфигураций (слушатели и advertised.listeners).

В некоторых средах может потребоваться проводить различие между внешними клиентами, внутренними клиентами и трафиком репликации независимо от протокола безопасности по соображениям стоимости, производительности и безопасности. Несколько примеров, которые иллюстрируют это:

• Трафик репликации назначается отдельному сетевому интерфейсу, чтобы он не мешал трафику клиента.
• Внешний трафик проходит через прокси/балансировщик нагрузки (безопасность, гибкость), в то время как внутренний трафик напрямую влияет на брокеров (производительность, стоимость).
• Различные параметры безопасности для внешнего и внутреннего трафика, даже если протокол безопасности одинаков (например, различный набор включенных механизмов SASL, серверов аутентификации, разных хранилищ ключей и т.д.)

В связи с этим мы предлагаем, чтобы брокеры Kafka могли иметь возможность определять несколько прослушивателей для одного и того же протокола безопасности для привязки (т.е. Прослушивателей) и совместного использования (т.е. Advertised.listeners), чтобы внутренний, внешний и репликационный трафик можно было разделить при необходимости.

Так,

слушатели - разделенный запятыми список URI, которые мы будем прослушивать, и их протоколы. Укажите имя хоста как 0.0.0.0 для привязки ко всем интерфейсам. Оставьте имя хоста пустым для привязки к интерфейсу по умолчанию. Примеры легальных списков слушателей:

• PLAINTEXT://myhost:9092,TRACE://:9091
• PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093

advertised.listeners - Слушатели для публикации в ZooKeeper для использования клиентами, если они отличаются от слушателей выше. В средах IaaS это может отличаться от интерфейса, с которым связывается брокер. Если это не установлено, будет использоваться значение для listeners.

Ответ 4

Работает нормально для меня, используя "advertised.listeners", н