解决Docker容器连接 Kafka 连接失败问题
提出问题
近日助友 Docker 部署 Kafka 服务,服务日志启动正常,但客户端却无法连接
往日曾踩过此坑,然方法均源于博客,其语焉不详,不知为何不行,亦不知为何行,印象不甚深刻,耗费大量时间
为避此坑,特地学习官方文档相关章节,让我寻到珠丝马迹,请听我娓娓道来~
如嫌篇幅较长,可跳过验证,直奔结论
本文主要记录为何会出现无法连接到 Broker 的原因,想必看完本文你会知道该怎么做的 😃
谨以此文献给那些因为无知而浪费的时光!
大胆猜测
Kafka的服务端称为 Broker
,每个 Broker 启动时会将自己的 Broker 配置信息上报给 Zookeeper
,如,监听地址与端口号等,Kafka的客户端(生产者与消费者统称)要连接 Broker 需要经过一层认证,不通过认证就无法连接!
小心求证
测试环境:
- GNU/Linux Debian 10 4.19.0内核
- Docker:
19.03.6
- Docker-compose:
1.17.1
- 镜像:
zookeeper:3.5.5
- 镜像:
wurstmeister/kafka:2.12-2.2.1
设计实验:
使用 docker 镜像部署一套单节点的 Zookeeper
+ Kafka
要求Broker监听自定义域名(主机名)与端口,服务启动后展示 Zookeeper
中 Broker
的注册信息
使用客户端连接 Broker
,使用不同的 --bootstrap-server
组合方式,进行验证
开始实验
为了提高部署效率,这里提供一个简单可启动的 docker-compose-test.yml
version: "3.3"
services:
zookeeper:
image: zookeeper:3.5.5
restart: always
container_name: zookeeper
ports:
- "2181:2181"
expose:
- "2181"
environment:
- ZOO_MY_ID=1
kafka:
image: wurstmeister/kafka:2.12-2.2.1
restart: always
container_name: kafka
environment:
- KAFKA_BROKER_ID=1
- KAFKA_LISTENERS=PLAINTEXT://kafka:9090
- KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181
- KAFKA_MESSAGE_MAX_BYTES=2000000
ports:
- "9090:9090"
depends_on:
- zookeeper
将 docker-compose-test.yml
放入你的目录,运行部署脚本
查看两者的日志,检查是否正常启动
docker logs -f zookeeper
docker logs -f kafka
可以看到 Kafka 已经注册成功
让我们查看一下,Zookeeper 中注册的 Broker 信息
docker exec -it zookeeper bash bin/zkCli.sh
输入 quit
退出
想到我们已经将Kafka监听的端口号已经映射到宿主机了,使用宿主机 IP 访问不就得了?
先创建个Topic
docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \
bash /opt/kafka/bin/kafka-topics.sh \
--bootstrap-server 192.168.1.19:9090 \
--create --topic logsTopic --partitions 1 --replication-factor 1
噢!又是这该死的错误!
想到刚才在 zookeeper
中看到的信息,要不我把 IP 换成 kafka
不就结了?
docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \
bash /opt/kafka/bin/kafka-topics.sh \
--bootstrap-server kafka:9090 \
--create --topic logsTopic --partitions 1 --replication-factor 1
不对,宿主机本身没有对 kafka
作映射,问题一定出在这里!
再次执行刚才的命令,没有输出,说明创建 Topic 成功!
生产一条消息测试下
docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \
bash /opt/kafka/bin/kafka-console-producer.sh \
--broker-list kafka:9090 --topic logsTopic
输入回车,发送消息; ctrl + c 断开连接
创建消费者,消费消息测试
docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \
bash /opt/kafka/bin/kafka-console-consumer.sh \
--bootstrap-server kafka:9090 --topic logsTopic --from-beginning
嗯,消费也成功了
归纳总结
这个实验说明了什么呢?
说明 Kafka 客户端在连接 Broker 的时候,Broker 将客户端发来的请求带的信息与 Broker 启动时上报给 Zookeeper 的信息 进行了比对,比对相同则认证通过,反之建立连接失败!
官方文档
通过耐心地查看 Kafka
的官方文档,终于在角落里看到她的影子!(好久不见妹子,看文档都眉清目秀的~)
比如下面这段:
From Kafka version 2.0.0 onwards, host name verification of servers is enabled by default for client connections as well as inter-broker connections to prevent man-in-the-middle attacks.
大意是讲通过这种认证hostname
的机制,来避免中间人攻击
还有这段:
advertised.host.name: DEPRECATED: only used when
advertised.listeners
orlisteners
are not set. Useadvertised.listeners
instead. Hostname to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, it will use the value forhost.name
if configured. Otherwise it will use the value returned from java.net.InetAddress.getCanonicalHostName().
虽然这个参数已经标记为废弃了,但是她提供了个信息:如果设置主机名可能会被上报
最后看看这段
advertised.listeners: Listeners to publish to ZooKeeper for clients to use, if different than the
listeners
config property. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value forlisteners
will be used. Unlikelisteners
it is not valid to advertise the 0.0.0.0 meta-address.
也就是说,默认设置 advertised.listeners
与 listeners
的值相同,上报Zookeeper供客户端使用;无需绑定不同接口时,只需要设置 listeners
即可。
结论
Kafka 客户端在连接 Broker 的时候,Broker 将客户端发来的请求附加信息与 Broker 启动时上报给 Zookeeper 的 listeners参数信息、host(来自listeners的中间域名或主机名部分)、port (来自listeners的端口部分) 进行了验证,认证通过建立连接执行请求,反之建立连接失败
如果看完本文还不知如何去做,请参考https://www.cnblogs.com/hellxz/p/how_to_add_hosts_on_docker.html
写这篇文章费了好大的功夫,猜是一回事,弄明白又是一回事,如果本文对你有所帮助,欢迎点推荐与关注
引用:
https://kafka.apache.org/documentation.html
本文采用 CC BY 4.0 协议进行授权,转载请标注作者署名及来源。
https://www.cnblogs.com/hellxz/p/why_cnnect_to_kafka_always_failure.html