Kafka via en proxy: bootstrap fungerar, brokeranslutningar misslyckas
Förklarar varför en lyckad Kafka-bootstrap inte garanterar proxy-åtkomst till varje upptäckt broker.
En bootstrap-anslutning kan lyckas medan Kafka-klienten fortfarande inte kan producera eller konsumera. Bootstrap-servrar hjälper klienten att upptäcka klustret; de är inte nödvändigtvis de enda slutpunkter den kontaktar.
Broker-metadata innehåller adresser som används för senare anslutningar. Om dessa namn eller portar inte går att nå via den avsedda proxy-vägen löser inte den första lyckade anslutningen resten av jobbet.
Läs de annonserade slutpunkterna
Jämför bootstrap-adressen med de broker-adresser klienten faktiskt tar emot. Ett offentligt bootstrap-alias kan leda till privata annonserade namn, och vidarebefordran av en enda lokal port skriver inte automatiskt om varje adress i metadata.
Identifiera också den proxy-väg som klientimplementeringen stöder. En Java-system-SOCKS-egenskap är ingen garanti för att ett biblioteks NIO-baserade transport använder JDK Socket-proxymekanismen. Kontrollera den faktiska Kafka-klienten och nätverksintegrationen istället för att anta att varje Java-socket respekterar samma inställning.
En proxy-medveten klient behöver en tillåten väg till de relevanta broker-slutpunkterna. En nätverksnivåordning behöver motsvarande nåbarhet och namnmatchning. Det är olika konstruktioner, och ingen av dem tillhandahålls bara genom att lista en proxy som bootstrap-server.
Håll säkerhetsprotokoll och autentiseringsinställningar åtskilda. En proxy kan upprätta en TCP-väg medan TLS-identitet, SASL-autentisering eller broker-auktorisering fortfarande misslyckas.
Vid diagnostik, notera vilken slutpunkt som misslyckades och om den kom från statisk konfiguration eller returnerad metadata. Den skillnaden begränsar problemet mycket mer än att upprepade gånger ändra en slutpunkt som redan var nåbar.