Kafka控制台生产者无法连接SASL认证Broker问题求助

你遇到的这个连接节点-1的警告，通常是客户端没拿到有效的Broker地址，或者SASL握手失败导致的。结合你给出的信息，咱们从这几个关键方向排查：

先明确问题场景 #

你用这条命令启动控制台生产者：

KAFA_HEAP_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true" \
bin/kafka-console-producer.sh \
--broker-list server-01.eigenroute.com:9092 --topic test-topic \
--producer.config config/sasl-producer.properties

发送消息后反复出现：

test message
[2018-01-06 15:29:10,724] WARN [Producer clientId=console-producer] Connection to node -1 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
[2018-01-06 15:29:10,816] WARN [Producer clientId=console-producer] Connection to node -1 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)

虽然Broker已经完成ZooKeeper SASL认证、集群初始化，hosts也映射了域名，ZooKeeper里的Broker节点信息正常，但客户端就是连不上——核心问题大概率出在SASL认证配置不匹配或者Broker地址暴露配置错误上。

1. 先检查生产者配置文件sasl-producer.properties #

这是最容易踩坑的地方，你得确保配置里包含了SASL认证的核心参数：

• 必须指定security.protocol：如果是明文SASL就设为SASL_PLAINTEXT，如果加了SSL就设为SASL_SSL，缺省的话客户端会用默认的PLAINTEXT，根本不会发起SASL握手
• sasl.mechanism要和Broker配置完全一致（比如GSSAPI、PLAIN、SCRAM-SHA-256等），比如Broker用Kerberos的话，这里就得写GSSAPI
• 如果是Kerberos认证，还得配置sasl.jaas.config，举个例子：

sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
    useKeyTab=true \
    keyTab="/opt/kafka/producer.keytab" \
    principal="kafka-producer@EIGENROUTE.COM";

要是这些参数缺了或者错了，客户端连SASL握手都发起不了，自然连不上Broker。

2. 核对Broker的listeners和advertised.listeners配置 #

打开Broker的config/server-sasl-brokers-zookeeper.properties，重点看这两个参数：

• listeners是Broker实际监听的地址，必须带SASL协议前缀，比如SASL_PLAINTEXT://server-01.eigenroute.com:9092，不能只写server-01.eigenroute.com:9092
• advertised.listeners是Broker对外暴露给客户端的地址，必须和你生产者命令里的--broker-list完全一致！如果这里配置的是别的地址（比如内网IP、不带协议前缀），生产者从ZooKeeper拿到的Broker地址就不对，就会出现连接节点-1的错误（节点-1表示客户端还没获取到可用的Broker节点信息）

3. 检查Broker的JAAS配置文件 #

Broker的jaas.conf必须正确配置客户端认证的规则，比如Kerberos场景下，KafkaServer条目得包含Broker自己的主体和keytab，同时允许客户端的Kerberos主体访问：

KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    keyTab="/opt/kafka/broker.keytab"
    principal="kafka/server-01.eigenroute.com@EIGENROUTE.COM";
};

另外，生产者的JAAS配置里的主体必须是Broker的Kerberos环境认可的，keytab文件的权限也要对（得让生产者进程能读）。

4. 利用Kerberos调试日志找线索 #

你已经加了-Dsun.security.krb5.debug=true，这太有用了！仔细看日志里的Kerberos相关输出，比如：

• 有没有提示无法读取krb5.conf？
• 有没有说获取Kerberos票据失败（比如principal不存在、keytab路径错了）？
• 有没有KDC拒绝认证的报错？
  这些细节能直接告诉你认证失败的具体原因，比单纯的连接警告有用多了。

5. 最后确认网络连通性 #

虽然hosts已经映射，但还是用nc -zv server-01.eigenroute.com 9092或者telnet server-01.eigenroute.com 9092测一下端口是否能通，确保Broker确实在监听9092端口，同时检查防火墙有没有拦截这个端口的流量。

总结 #

大概率是生产者SASL配置不全、Broker的advertised.listeners配置错误，或者Kerberos主体/keytab不匹配导致的。建议先把生产者和Broker的SASL核心配置核对一遍，再结合Kerberos调试日志定位具体问题。

内容的提问来源于stack exchange，提问作者Shafique Jamal