Kafka deur 'n proxy: bootstrap werk, broker-verbindings misluk
Verduidelik waarom 'n suksesvolle Kafka-bootstrap nie beteken dat die proxy elke ontdekte broker kan bereik nie.
'n Bootstrap-verbinding kan slaag terwyl die Kafka-kliënt steeds nie kan produseer of verbruik nie. Bootstrap-bedienerers help die kliënt om die cluster te ontdek; hulle is nie noodwendig die enigste eindpunte wat dit sal kontak nie.
Broker-metadata bevat adresse wat vir latere verbindings gebruik word. As daardie name of poorte nie deur die beoogde proxy-roete bereikbaar is nie, los die eerste suksesvolle verbinding nie die res van die taak op nie.
Lees die geadverteerde eindpunte
Vergelyk die bootstrap-adres met die broker-adresse wat die kliënt werklik ontvang. 'n Openbare bootstrap-alias kan na private geadverteerde name lei, en die deurstuur van een plaaslike poort herskryf nie outomaties elke adres in metadata nie.
Identifiseer ook die proxy-pad wat die kliënt-implementering ondersteun. 'n Java-stelsel-SOCKS-eienskap is nie 'n waarborg dat 'n biblioteek se NIO-gebaseerde vervoer die JDK Socket-proxy-meganisme gebruik nie. Kontroleer die werklike Kafka-kliënt en netwerkintegrasie eerder as om aan te neem dat elke Java-socket dieselfde instelling respekteer.
'n Proxy-bewuste kliënt het 'n toegelate roete na die betrokke broker-eindpunte nodig. 'n Reëling op netwerkvlak vereis ooreenstemmende bereikbaarheid en naamresolusie. Dit is verskillende ontwerpe, en nie een word bloot verskaf deur 'n proxy as 'n bootstrap-bediener te lys nie.
Hou sekuriteitsprotokol en verifikasie-instellings apart. 'n Proxy kan 'n TCP-pad vestig terwyl TLS-identiteit, SASL-verifikasie of broker-magtiging steeds misluk.
Vir diagnose, let op watter eindpunt gefaal het en of dit uit statiese konfigurasie of teruggekeerde metadata gekom het. Daardie onderskeid vernou die probleem baie meer as om herhaaldelik 'n eindpunt te verander wat reeds bereikbaar was.