Kafka через проксі: bootstrap працює, а з'єднання з брокерами не вдаються
Пояснює, чому успішне bootstrap-з'єднання Kafka не гарантує доступу через проксі до кожного виявленого брокера.
Bootstrap-з'єднання може встановитися успішно, хоча клієнт Kafka досі не може виробляти або споживати. Bootstrap-сервери допомагають клієнту виявити кластер; вони не обов'язково є єдиними кінцевими точками, до яких він підключиться.
Метадані брокера містять адреси, що використовуються для подальших з'єднань. Якщо ці імена або порти недоступні через передбачуваний маршрут проксі, перше успішне з'єднання не вирішує решту завдання.
Прочитайте оголошені кінцеві точки
Порівняйте bootstrap-адресу з адресами брокерів, які клієнт фактично отримує. Публічний псевдонім bootstrap може вести до приватних оголошених імен, а перенаправлення одного локального порту не переписує автоматично кожну адресу в метаданих.
Також визначте шлях проксі, який підтримує реалізація клієнта. Властивість SOCKS системи Java не гарантує, що транспорт бібліотеки на основі NIO використовує проксі-механізм JDK Socket. Перевіряйте фактичний клієнт Kafka і мережеву інтеграцію, а не припускайте, що кожен сокет Java дотримується того самого налаштування.
Клієнту, який враховує проксі, потрібен дозволений маршрут до відповідних кінцевих точок брокерів. Мережеве рішення потребує відповідної досяжності та розв'язання імен. Це різні проєкти, і жоден із них не забезпечується лише зазначенням проксі як bootstrap-сервера.
Тримайте налаштування протоколу безпеки й автентифікації окремо. Проксі може встановити шлях TCP, поки ідентичність TLS, автентифікація SASL або авторизація брокера все ще не працюють.
Для діагностики зазначте, яка кінцева точка не спрацювала і чи походить вона зі статичної конфігурації або з повернених метаданих. Ця відмінність значно звужує проблему, ніж повторна зміна вже доступної кінцевої точки.