Kafka printr-un proxy: bootstrap-ul funcționează, conexiunile la brokeri eșuează

O conexiune bootstrap poate reuși în timp ce clientul Kafka încă nu poate produce sau consuma. Serverele bootstrap ajută clientul să descopere clusterul; nu sunt neapărat singurele endpointuri cu care se va conecta.

Metadatele brokerului conțin adrese folosite pentru conexiuni ulterioare. Dacă acele nume sau porturi nu sunt accesibile prin ruta proxy dorită, prima conexiune reușită nu rezolvă restul lucrării.

Citiți endpointurile anunțate

Comparați adresa bootstrap cu adresele de broker pe care clientul le primește efectiv. Un alias bootstrap public poate duce la nume anunțate private, iar redirecționarea unui singur port local nu rescrie automat fiecare adresă din metadate.

Identificați și calea proxy acceptată de implementarea clientului. O proprietate SOCKS de sistem Java nu garantează că transportul unei biblioteci bazat pe NIO folosește mecanismul proxy Socket al JDK. Verificați clientul Kafka real și integrarea de rețea în loc să presupuneți că fiecare socket Java respectă aceeași setare.

Un client conștient de proxy are nevoie de o rută permisă către endpointurile de broker relevante. O amenajare la nivel de rețea are nevoie de accesibilitate și rezoluție de nume corespunzătoare. Sunt proiecte diferite și niciunul nu este oferit doar prin listarea unui proxy ca server bootstrap.

Păstrați separate setările de protocol de securitate și de autentificare. Un proxy poate stabili o rută TCP în timp ce identitatea TLS, autentificarea SASL sau autorizarea brokerului încă eșuează.

Pentru diagnostic, notați care endpoint a eșuat și dacă provine din configurația statică sau din metadate returnate. Această distincție restrânge problema mult mai mult decât schimbarea repetată a unui endpoint care era deja accesibil.