Kafka via un proxy : le bootstrap fonctionne, les connexions aux brokers échouent

Une connexion bootstrap peut réussir alors que le client Kafka ne peut toujours pas produire ni consommer. Les serveurs bootstrap aident le client à découvrir le cluster ; ils ne sont pas forcément les seuls points de terminaison qu'il contactera.

Les métadonnées du broker contiennent des adresses utilisées pour les connexions ultérieures. Si ces noms ou ports ne sont pas joignables via la route proxy prévue, la première connexion réussie ne résout pas le reste du travail.

Lire les points de terminaison annoncés

Comparez l'adresse bootstrap aux adresses de broker que le client reçoit réellement. Un alias bootstrap public peut mener à des noms annoncés privés, et le transfert d'un seul port local ne réécrit pas automatiquement toutes les adresses des métadonnées.

Identifiez aussi la voie proxy prise en charge par l'implémentation du client. Une propriété SOCKS système Java ne garantit pas qu'un transport de bibliothèque basé sur NIO utilise le mécanisme proxy de Socket du JDK. Vérifiez le client Kafka réel et l'intégration réseau au lieu de supposer que chaque socket Java respecte le même réglage.

Un client conscient du proxy a besoin d'une route autorisée vers les points de terminaison de broker concernés. Un dispositif au niveau réseau a besoin d'une joignabilité et d'une résolution de noms correspondantes. Ce sont des conceptions différentes, et aucune n'est fournie simplement en listant un proxy comme serveur bootstrap.

Gardez séparés les réglages du protocole de sécurité et de l'authentification. Un proxy peut établir une route TCP tandis que l'identité TLS, l'authentification SASL ou l'autorisation du broker échouent encore.

Pour le diagnostic, notez quel point de terminaison a échoué et s'il provient d'une configuration statique ou de métadonnées renvoyées. Cette distinction circonscrit bien mieux le problème que de modifier à répétition un point de terminaison déjà joignable.