[转帖]解释docker单机部署kraft模式kafka集群时,尝试各种方式的网络broker全部不通而启动失败的原因,并提示常见bug关注点

解释,docker,单机,部署,kraft,模式,kafka,集群,尝试,各种,方式,网络,broker,全部,不通,启动,失败,原因,提示,常见,bug,关注点 · 浏览次数 : 0

小编点评

**问题:** * controller节点与其他两个broker的通信失败。 * 公网ip,宿主机ip,服务名,端口等信息未提供,难以进行具体分析。 **解决方案:** 1. **确定问题所在:**首先,需要确定问题是否源于controller节点、其他broker还是网络配置问题。可以尝试使用 `docker logs` 等工具获取容器日志,分析其输出信息。 2. **检查网络连接性:**确保所有容器都可以正常访问 nhau的IP地址和端口。可以使用 `ping` 等工具测试网络连接性。 3. **检查网络配置:**确认所有 broker 和 controller 都设置了正确的网络地址和端口。检查防火墙规则是否影响了网络流量。 4. **检查日志信息:**分析 controller 和 broker 的日志信息,查找是否有任何异常或错误信息。 5. **确认端口绑定:**确保所有容器都成功绑定了端口。可以使用 `lsof` 等工具检查端口绑定的进程。 6. **测试其他端口:**尝试将 `KAFKA_HEAP_OPTS` 设置为其他值,例如 256m,尝试启动容器。 7. **重启容器:**重启所有容器,确保它们重新启动并设置正确的端口。 **其他建议:** * 使用 `docker ps` 等工具查看容器的端口配置。 * 使用 `docker exec` 命令运行容器,并使用 `ps` 等工具查看其端口信息。 * 使用 `docker logs` 等工具获取容器的日志信息。

正文

现象:
controller节点与其他两个broker的通信失败公网ip,宿主机ip,服务名,各种网络方式,都无法成功。


两点提示:

1.bug原因:因为单机内存不够用,设置了较低的 KAFKA_HEAP_OPTS 参数值128M,导致broker通信失败!

2.kafka容器启动中,增加 BITNAMI_DEBUG=true 参数,可通过 docker logs 命令查看更为细节的日志信息!


以下为 执行 docker-compose up -d 时,会成功的 docker-compose.yml文件内容:

version: "2.12"
services:
    kafkas1:
        image: 'bitnami/kafka:3.2.3'
        container_name: kafkas1
        user: root
        ports:
            - '9092:9092'
            - '9093:9093'
        environment:
            - KAFKA_ENABLE_KRAFT=yes
            - KAFKA_CFG_PROCESS_ROLES=broker,controller
            - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
            - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093
            - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
            - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafkas1:9092
            - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT
            - KAFKA_NODE_ID=1
            - KAFKA_CFG_BROKER_ID=1
            - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafkas1:9093,2@kafkas2:9095,3@kafkas3:9097
            - ALLOW_PLAINTEXT_LISTENER=yes
            - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
            - KAFKA_KRAFT_CLUSTER_ID=7es-47FeQpCKpLfsN1uPxQ
            - BITNAMI_DEBUG=true
        volumes:
            - /usr/local/kafka/kafka1/data:/bitnami/kafka
        networks:
            - kafka_standalone_net
    kafkas2:
        image: 'bitnami/kafka:3.2.3'
        container_name: kafkas2
        user: root
        ports:
            - '9094:9094'
            - '9095:9095'
        environment:
            - KAFKA_ENABLE_KRAFT=yes
            - KAFKA_CFG_PROCESS_ROLES=broker,controller
            - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
            - KAFKA_CFG_LISTENERS=PLAINTEXT://:9094,CONTROLLER://:9095
            - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
            - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafkas2:9094
            - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT
            - KAFKA_NODE_ID=2
            - KAFKA_CFG_BROKER_ID=2
            - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafkas1:9093,2@kafkas2:9095,3@kafkas3:9097
            - ALLOW_PLAINTEXT_LISTENER=yes
            - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
            - KAFKA_KRAFT_CLUSTER_ID=7es-47FeQpCKpLfsN1uPxQ
            - BITNAMI_DEBUG=true
        volumes:
            - /usr/local/kafka/kafka2/data:/bitnami/kafka
        networks:
            - kafka_standalone_net
    kafkas3:
        image: 'bitnami/kafka:3.2.3'
        container_name: kafkas3
        user: root
        ports:
            - '9096:9096'
            - '9097:9097'
        environment:
            - KAFKA_ENABLE_KRAFT=yes
            - KAFKA_CFG_PROCESS_ROLES=broker,controller
            - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
            - KAFKA_CFG_LISTENERS=PLAINTEXT://:9096,CONTROLLER://:9097
            - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
            - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafkas3:9096
            - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT
            - KAFKA_NODE_ID=3
            - KAFKA_CFG_BROKER_ID=3
            - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafkas1:9093,2@kafkas2:9095,3@kafkas3:9097
            - ALLOW_PLAINTEXT_LISTENER=yes
            - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
            - KAFKA_KRAFT_CLUSTER_ID=7es-47FeQpCKpLfsN1uPxQ
            - BITNAMI_DEBUG=true
        volumes:
            - /usr/local/kafka/kafka3/data:/bitnami/kafka
        networks:
            - kafka_standalone_net
networks:
    kafka_standalone_net:
        driver: bridge

    topic,producer,consumer,测试相关命令:

    # 随便进入一个容器节点
    docker exec -it kafkas1 /bin/bash
    # 创建topic,1个partition,1个replication
    /opt/bitnami/kafka/bin/kafka-topics.sh --bootstrap-server kafkas1:9092 --create --topic firsttopic --partitions 1 --replication-factor 1
    # 查看已存在topic列表
    /opt/bitnami/kafka/bin/kafka-topics.sh --bootstrap-server kafkas1:9092 --list
    # 创建producer
    /opt/bitnami/kafka/bin/kafka-console-producer.sh --bootstrap-server kafkas1:9092 --topic firsttopic
    

    # 再起一个窗口,随便连接一个容器节点,创建consumer
    docker exec -it kafkas1 /bin/bash
    /opt/bitnami/kafka/bin/kafka-console-consumer.sh --bootstrap-server kafkas1:9092 --topic firsttopic

    ### 上面所有的 kafkas1,都可以随便替换为 kafkas2,kafkas3,任意节点都一样。
    ### 当然,端口要对应上


      如上内容,其他都不变,只把 KAFKA_HEAP_OPTS 参数值的 256m 改为 128m,就会失败

      我是因为测试服务器内存实在太小,才会特意设置这个参数,算是遇到了奇葩坑。

      官网没看到相关描述,整个文档搜索 heap ,就没有相关的,应该是没说明。
      个人猜测,是因为内存不足,导致controller和broker通信时,网络IO链条上的某个部位内存分配函数调用失败,无法工作了。

      另外,我的测试服务器是2G内存,基本算是只有docker和kafka了,设置完256m以后,创建一个topic时,partition、replication都设置了1,要不然,后面再创建producer时,又内存不足失败了。


      其他常见关注点:

      1. KAFKA_ENABLE_KRAFT=yes参数,代表kraft模式,也就是弃用zookeeper
      2. 一个节点,可以为broker,可以为controller,也可以同时broker和controller
      3. listeners是描述本节点监听哪里(包括监听客户端的,和其他broker和controller的),advertised.listeners是告诉controller节点客户端访问我哪里
      4. controller.listener.names是说明controller相关通信用哪个名字的协议,inter.broker.listener.name是说明broker相关通信用哪个名字的协议。都在内网就用plaintext,都在公网就可以用ssl之类的,用来规划各个点之间通信安全的。
      5. KAFKA_KRAFT_CLUSTER_ID=7es-47FeQpCKpLfsN1uPxQ 是节点之间作为同一集群的标记,具体内容无所谓,你也可以用我的。

      顺便想问一下:
      为什么上面的docker-compose.yml中,9093,9095,9097,端口不暴露出去,也可以启动成功,正常使用???以我的理解,不应该呀!懂的教教我

      文章知识点与官方知识档案匹配,可进一步学习相关知识

      与[转帖]解释docker单机部署kraft模式kafka集群时,尝试各种方式的网络broker全部不通而启动失败的原因,并提示常见bug关注点相似的内容:

      [转帖]解释docker单机部署kraft模式kafka集群时,尝试各种方式的网络broker全部不通而启动失败的原因,并提示常见bug关注点

      现象: controller节点与其他两个broker的通信失败。公网ip,宿主机ip,服务名,各种网络方式,都无法成功。 两点提示: 1.bug原因:因为单机内存不够用,设置了较低的 KAFKA_HEAP_OPTS 参数值128M,导致broker通信失败! 2.kafka容器启动中,增加 BIT

      [转帖]解决Harbor在服务器重启后无法自启动的问题

      问题 当部署Harbor的服务器在重启之后,可能会出现Harbor无法跟随系统自启动 解决方案 现假设Harbor的安装目录位置为/usr/local/harbor,在Harbor安装完成之后,在此目录下会生成docker-compose.yml配置文件,可以使用docker-compose操作此文

      [转帖]kubelet 原理解析六: 垃圾回收

      https://segmentfault.com/a/1190000022163856 概述 在k8s中节点会通过docker pull机制获取外部的镜像,那么什么时候清除镜像呢?k8s运行的容器又是什么时候清除呢? api-server: 运行在master,无状态组件,go自动内存垃圾回收 co

      [转帖]查看docker中运行的JVM参数问题及解决方法

      方法一、jcmd命令: 1、jps获取java的线程id 2、jcmd pidVM.flags获取 51152:-XX:CICompilerCount=3 -XX:InitialHeapSize=526385152 -XX:MaxHeapSize=1073741824 -XX:MaxNewSize=

      [转帖]DOCKER默认网段和主机网段冲突解决

      https://www.cnblogs.com/yinliang/p/13189334.html 一、 docker默认网卡docker0 172.17.0.0可能会与主机冲突,这时候需要修改docker默认分配的网段 1、修改/etc/docker/daemon.json文件,加入以下代码 {"d

      【转帖】通过docker配置DNS服务

      https://blog.whsir.com/post-3185.html 在办公室开发人员经常会测试所写的页面,每次都要输入对应的IP地址或者更改hosts,为了让开发大爷省心,不如搭建一个dns服务,将所需要测试的网页直接解析成域名,让开发大爷自己选域名,想用啥就用啥,我这里通过docker配置

      [转帖]【杂学第十二篇】oracledb_exporter监听oracle19c数据库出现libclntsh、ORA-12162、ORA-00942异常解决

      http://www.taodudu.cc/news/show-4845374.html docker run -d --name oracledb_exporter --restart=always -p 9161:9161 -e DATA_SOURCE_NAME='sys/Test2013112

      [转帖]制作本地docker-ce镜像仓库(使用reposync、createrepo、httpd)

      记录:330 场景:在CentOS 7.9操作系统上,使用reposync从开源镜像站下载docker-ce镜像仓库的rpm包;使用createrepo制作本地docker-ce镜像仓库;使用httpd发布服务。解决内网中使用yum命令安装docker-ce的需求。 版本: 操作系统:CentOS

      [转帖]docker 镜像分层原理及容器写时复制

      https://xie.infoq.cn/article/19c98e8b15ff9f610a2ee26bd 一、镜像分层与容器层 在进行docker pull 下载镜像的时候,通过下图可以看到镜像是分层下载并解压的。如 nginx:1.20.2 的镜像,其镜像是分为 6 层。 当我们运行一个新的容

      [转帖]Docker容器日志查看与清理(亲测有效)

      1. 问题 docker容器日志导致主机磁盘空间满了。docker logs -f container_name噼里啪啦一大堆,很占用空间,不用的日志可以清理掉了。 2. 解决方法 2.1 找出Docker容器日志 在linux上,容器日志一般存放在/var/lib/docker/container