Configuration du serveur Kafka - listeners vs. advertised.listeners

Question

Pour faire fonctionner Kafka, vous devez définir certaines propriétés dans le fichier config/server.properties fichier. Il y a deux paramètres que je ne comprends pas.

Quelqu'un peut-il expliquer la différence entre les listeners et la propriété advertised.listeners ?

La documentation dit :

les auditeurs : L'adresse sur laquelle le serveur de socket écoute.

y

advertised.listeners : Nom d'hôte et port que le courtier annoncera aux producteurs et aux consommateurs.

Quand dois-je utiliser quel paramètre ?

Answer 1

listeners est ce que le courtier utilisera pour créer les sockets du serveur.

advertised.listeners est ce que les clients utiliseront pour se connecter aux courtiers.

Les deux paramètres peuvent être différents si vous avez une configuration réseau "complexe" (avec des éléments tels que des sous-réseaux publics et privés et du routage entre les deux).

Answer 2

Puisque je ne peux pas encore commenter, je vais poster ceci comme une "réponse", en complément de la réponse de M.Situations.

Dans le même document qu'il met en lien, il y a cette information sur le listener qui est utilisé par un client KAFKA ( https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Séparation+du+trafic+intérieur+et+extérieur ) :

Comme indiqué précédemment, les clients ne voient jamais les noms des auditeurs et font des demandes de métadonnées exactement comme avant. La différence est que la liste des points de terminaison qu'ils reçoivent en retour est limitée au nom de l'auditeur du point de terminaison où ils ont fait la demande.

C'est important car selon l'URL que vous utilisez dans votre configuration bootstrap.servers, ce sera l'URL* que le client récupérera si elle est mappée dans advertised.listeners (je ne sais pas quel est le comportement si le listener n'existe pas).

Notez aussi ceci :

L'exception est constituée par les consommateurs basés sur ZooKeeper. Ces consommateurs récupèrent les informations d'enregistrement des courtiers directement à partir de ZooKeeper et choisiront le premier listener avec PLAINTEXT comme protocole de sécurité (le seul protocole de sécurité qu'ils supportent).

Comme exemple de configuration de courtier (pour tous les courtiers du cluster) :

advertised.listeners=EXTERNAL://XXXXX.compute-1.amazonaws.com:9990,INTERNAL://ip-XXXXX.ec2.internal:9993

inter.broker.listener.name=INTERNAL

listener.security.protocol.map=EXTERNAL:SSL,INTERNAL:PLAINTEXT

Si le client utilise XXXXX.compute-1.amazonaws.com:9990 pour se connecter, la récupération des métadonnées se fera auprès de ce courtier. Cependant, l'URL de retour à utiliser avec le coordinateur ou le chef de groupe pourrait être 123.compute-1.amazonaws.com:9990* (une machine différente !). Cela signifie que la correspondance est effectuée sur le nom de l'auditeur tel qu'annoncé par le KIP-103, indépendamment de l'URL réelle (nœud).

Comme la carte de protocole pour EXTERNAL est SSL, cela vous obligerait à utiliser un keystore SSL pour vous connecter.

Si, par contre, vous vous trouvez dans AWS, par exemple, vous pouvez alors envoyer ip-XXXXX.ec2.internal:9993 et la connexion correspondante sera en texte clair, conformément à la carte de protocole.

Cela est particulièrement nécessaire dans le domaine IaaS où, dans mon cas, les courtiers et les consommateurs vivent sur AWS, tandis que mon producteur vit sur le site d'un client, ce qui nécessite des protocoles de sécurité et des écouteurs différents.

EDIT : L'ajout de règles entrantes est également beaucoup plus facile maintenant que vous avez différents ports pour différents clients (courtiers, producteurs, consommateurs).

EDIT2 : Cet article est un excellent guide approfondi si ce qui précède n'est toujours pas clair : https://rmoff.net/2018/08/02/kafka-listeners-explained/

Answer 3

De ce lien : https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Séparation+du+trafic+intérieur+et+extérieur

Au cours du cycle de publication de la version 0.9.0.0, la prise en charge de plusieurs listeners par courtier a été introduit. Chaque écouteur est associé à un protocole de sécurité protocole de sécurité, un ip/host et un port. En combinaison avec le mécanisme des d'auditeurs annoncés, il y a une bonne dose de flexibilité avec une limitation limitation : au maximum un listener par protocole de sécurité dans chacune des deux deux configurations (listeners et advertised.listeners).

Dans certains environnements, on peut vouloir faire la différence entre des clients externes, les clients internes et le trafic de réplication indépendamment du protocole de sécurité pour des raisons de coût, de performance et de sécurité. Quelques exemples qui illustrent ceci :

• Le trafic de réplication est affecté à une interface réseau distincte afin qu'il n'interfère pas avec le trafic client.
• Le trafic externe passe par un proxy/équilibreur de charge (sécurité, flexibilité) tandis que le trafic interne atteint directement les brokers. (performance, coût).
• Des paramètres de sécurité différents pour le trafic externe et le trafic interne, même si le protocole de sécurité est le même (par exemple, un jeu différent de mécanismes SASL activés, serveurs d'authentification, keystores différents, etc, etc.)

En tant que tel, nous proposons que les courtiers Kafka soient en mesure de définir pour un même protocole de sécurité pour la liaison (c'est-à-dire les listeners) et le partage (i.e. advertised.listeners) afin que le trafic interne, externe et de réplication puissent être séparés si nécessaire.

Donc,

listeners - Liste, séparée par des virgules, des URI que nous écouterons et de leurs protocoles. Spécifiez le nom d'hôte comme 0.0.0.0 pour se lier à toutes les interfaces. Laissez le nom d'hôte vide pour se lier à l'interface par défaut. Exemples de listes d'auditeurs légales :

• PLAINTEXT://myhost:9092,TRACE://:9091
• PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093

advertised.listeners - Les écouteurs à publier à ZooKeeper pour que les clients les utilisent, s'ils sont différents des écouteurs ci-dessus. Dans les environnements IaaS, ceci peut être différent de l'interface à laquelle le broker se lie. Si ce paramètre n'est pas défini, la valeur de listeners sera utilisé.

Answer 4

Il y a tellement de confusion ou peu d'informations dans les réponses fournies ici pour cette question. Je poste donc ma réponse élaborée pour plus de clarté.

1. listeners - Utilisé par le serveur web jetty intégré à kafka pour se lier. Ce serveur web jetty est utilisé pour fournir l'API REST qui fournit le plan de contrôle pour les travailleurs Kafka Connect. Le nom d'hôte dans ce paramètre peut être laissé vide si vous voulez que kafka se lie à localhost (il le fait en appelant InetAddress.getLocalHost().getCanonicalHostName() api java)
2. advertised.listeners : Cette adresse est publiée à zookeeper par chaque broker kafka. Si ce paramètre n'est pas défini, alors la valeur de listeners sera utilisé ici et publié dans zookeeper. C'est le seul but de ce paramètre pour notifier les autres. Les clients Kafka utilisent le paramètre 'advertised.listeners' publié dans zookeeper (comme le paramètre /brokers/ids/<id>/ # endpoints ) pour parler au courtier Kafka.

Maintenant, la question est de savoir pourquoi avoir deux réglages ? Pourquoi pas un seul réglage ? Disons que votre courtier kafka est assis derrière un proxy. Et tous les clients kafka doivent parler au proxy pour atteindre le courtier. Dans ce cas, nous voulons que le serveur jetty embarqué de kafka se lie à localhost et au port local, mais nous ne pouvons pas publier cela à zookeeper car les clients ne peuvent pas l'utiliser. Ainsi, l'administrateur de kafka peut définir le paramètre advertised.listeners à l'hôte et au port du proxy.

Aussi, dans certains de nos hôtes de production, InetAddress.getLocalHost().getCanonicalHostName() renvoie une valeur vide et donc le nom d'hôte de la configuration des auditeurs était vide, ce qui permettait à Jetty de se lier. Mais advertised.listeners a été publié à zookeeper comme NULL:9092 puisqu'il a pris la même valeur que listeners par défaut. Maintenant tous les brokers ont essayé de publier de cette façon à zookeeper et les brokers ont eu l'erreur suivante java.lang.IllegalArgumentException: requirement failed: Configured end points null:14092 comme advertised.listeners car NULL:9092 est déjà enregistré par le courtier 101. La solution consistait à modifier l'adresse advertised.listeners pour qu'il contienne le nom de l'hôte.