Kafka przez proxy: bootstrap działa, połączenia z brokerami zawodzą
Wyjaśnia, dlaczego udane połączenie bootstrap Kafki nie gwarantuje dostępu przez proxy do każdego wykrytego brokera.
Połączenie bootstrap może się udać, podczas gdy klient Kafki nadal nie może produkować ani konsumować. Serwery bootstrap pomagają klientowi odkryć klaster; nie są one jednak koniecznie jedynymi punktami końcowymi, z którymi się połączy.
Metadane brokera zawierają adresy używane do późniejszych połączeń. Jeśli te nazwy lub porty nie są osiągalne przez zamierzoną trasę proxy, pierwsze udane połączenie nie rozwiązuje resztę zadania.
Przeczytaj ogłoszone punkty końcowe
Porównaj adres bootstrap z adresami brokerów, które klient faktycznie otrzymuje. Publiczny alias bootstrap może prowadzić do prywatnych ogłoszonych nazw, a przekierowanie jednego lokalnego portu nie przepisuje automatycznie każdego adresu w metadanych.
Zidentyfikuj także ścieżkę proxy obsługiwaną przez implementację klienta. Właściwość SOCKS systemu Java nie gwarantuje, że transport biblioteki oparty na NIO korzysta z mechanizmu proxy Socket JDK. Sprawdź rzeczywistego klienta Kafki i integrację sieciową, zamiast zakładać, że każde gniazdo Java respektuje to samo ustawienie.
Klient świadomy proxy potrzebuje dozwolonej trasy do odpowiednich punktów końcowych brokera. Układ na poziomie sieci wymaga odpowiedniej osiągalności i rozwiązywania nazw. To różne projekty i żaden z nich nie powstaje wyłącznie przez wymienienie proxy jako serwera bootstrap.
Oddziel ustawienia protokołu bezpieczeństwa i uwierzytelniania. Proxy może ustanowić ścieżkę TCP, podczas gdy tożsamość TLS, uwierzytelnianie SASL lub autoryzacja brokera nadal zawodzą.
Do diagnozy zanotuj, który punkt końcowy zawiódł i czy pochodzi z konfiguracji statycznej, czy ze zwróconych metadanych. To rozróżnienie znacznie bardziej zawęża problem niż wielokrotne zmienianie punktu końcowego, który był już osiągalny.