可观测性开发工具前端后端【免费下载链接】openreplaySession replay, cobrowsing and product analytics you can self-host. Best for reproducing issues and iterating on your product.项目地址https://gitcode.com/gh_mirrors/op/openreplay点击查看免费下载OpenReplay 仓库在scripts/dockerfiles/kafka/目录中提供了一套基于容器Podman/Docker Compose的 Kafka 3.x 双节点集群部署方案。本文以仓库内的集群状态文档 CLUSTER_INFO.md 为骨架结合 docker-compose.yml、Dockerfile 与 start-kafka.sh 等源码完整讲解该集群的节点拓扑、KRaft 配置原理、Topic 生产消费验证流程以及日常运维所需的全部命令帮助你快速自建一套可复现、可验证、可扩展的 Kafka 环境。集群总览两节点、双角色、全功能复制该 Kafka 集群由两个节点组成当前状态为Successfully Running正常运行。每个节点都同时承担Broker消息代理与Controller控制器两种角色形成合并部署的 KRaft 架构不再依赖 ZooKeeper。节点角色与身份项目Node 1kafka-1Node 2kafka-2Node ID12角色Broker ControllerFollowerBroker ControllerLeader容器主机名kafka-1kafka-2数据目录/bitnami/kafka/bitnami/kafka运行用户UID 1001非 rootUID 1001非 root文档中明确标注 kafka-2 为 Controller Leaderkafka-1 为 Follower。在 KRaft 模式下控制器负责元数据管理与选举quorum 由两个节点共同组成对应KAFKA_CONTROLLER_QUORUM_VOTERS配置。端口映射容器内监听端口与宿主机映射关系如下节点内部 Broker 端口宿主机映射内部 Controller 端口宿主机映射kafka-190929092:909290939093:9093kafka-290929094:909290939095:9093该映射在 docker-compose.yml 与 docker-compose.yml 中定义两个节点的容器内部端口保持一致Broker 9092、Controller 9093仅通过宿主机端口区分避免本机端口冲突。这意味着容器间通信使用kafka-1:9092、kafka-2:9092宿主机上访问集群则使用localhost:9092kafka-1与localhost:9094kafka-2。网络与数据持久化所有容器接入同一个 bridge 网络kafka-network由 compose 文件networks段声明容器间通过主机名互通每个节点挂载独立的命名卷kafka-1-data与kafka-2-data到/bitnami/kafka确保重启后数据不丢失日志目录为/bitnami/kafka/logs镜像内通过LOG_DIR环境变量指定。关键特性KRaft 模式、版本锁定与集群 ID该集群的设计要点可从 CLUSTER_INFO.md 的 Key Features 一节归纳为四点Kafka 3.9.0锁定 3.x 大版本镜像构建时通过apk add kafka~3固定主版本见 Dockerfile保证镜像可重复构建KRaft 模式彻底移除 ZooKeeper控制器职责内嵌进 Broker 进程简化部署与运维共享集群 IDSjg_Rr1iQbO9xpahgDbYpQ被两个节点共用这是多 Broker 组成同一逻辑集群的前提复制功能完整可用两个节点间副本同步正常可以安全地创建--replication-factor 2的 Topic。在 start-kafka.sh 中可以看到 KRaft 初始化逻辑首次启动时若数据目录中不存在meta.properties脚本会优先使用KAFKA_CLUSTER_ID环境变量指定的集群 ID否则读取/bitnami/kafka/cluster.id文件再否则随机生成并落盘然后执行kafka-storage.sh format -t $CLUSTER_ID -c $CONFIG_FILE完成存储格式化。只有所有节点传入同一个 Cluster IDKRaft 多节点集群才能形成统一 Quorum——这正是docker-compose.yml中两个服务都配置KAFKA_CLUSTER_ID: Sjg_Rr1iQbO9xpahgDbYpQ的原因。从 compose 文件读懂集群启动配置双节点集群的完整定义位于 docker-compose.yml。两个服务共享同一套镜像与启动逻辑仅KAFKA_NODE_ID、KAFKA_ADVERTISED_LISTENERS和宿主机端口映射不同。以下是 kafka-1 的核心环境变量kafka-2 同理environment: KAFKA_NODE_ID: 1 # 节点唯一 ID KAFKA_CLUSTER_ID: Sjg_Rr1iQbO9xpahgDbYpQ # 两个节点共享的集群 ID KAFKA_PROCESS_ROLES: broker,controller # 单进程同时承担两种角色 KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka-1:9092 KAFKA_CONTROLLER_QUORUM_VOTERS: 1kafka-1:9093,2kafka-2:9093 KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_LOG_DIRS: /bitnami/kafka/data LOG_DIR: /bitnami/kafka/logs这些变量对应的 Kafka 底层配置由 start-kafka.sh 生成/tmp/server.properties时写入node.idBroker/Controller 在集群内的唯一身份process.rolesbroker,controller节点同时充当消息代理与元数据控制器listeners声明监听器及其端口CONTROLLER监听器专用于控制器间通信advertised.listeners向客户端广播的对外地址容器部署时必须与内部监听地址保持一致kafka-1:9092否则客户端会连接失败controller.quorum.voters1kafka-1:9093,2kafka-2:9093列出全部控制器投票成员格式为nodeIdhost:port是 KRaft 选举的基础controller.listener.namesCONTROLLER与inter.broker.listener.namePLAINTEXT分别指定控制器通信与 Broker 间复制使用的监听器。镜像本身基于Chainguard Wolfi精简基础镜像构建Dockerfile安装kafka~3 openssl bash tini以非 root 用户1001运行并通过/sbin/tini作为 PID 1 启动脚本兼顾安全性与进程信号处理。如果你只想查看生成后的完整配置可以执行podman exec kafka-1 cat /tmp/server.properties验证集群创建 Topic、生产与消费消息CLUSTER_INFO.md 的 Testing the Cluster 一节提供了完整的端到端验证流程可直接在宿主机上依次执行。1. 创建 Topic指定副本数与分区数以下命令在 kafka-1 上创建名为my-topic的 Topic要求2 个副本两个 Broker 各存一份充分验证复制能力和3 个分区podman exec kafka-1 /usr/lib/kafka/bin/kafka-topics.sh \ --create --topic my-topic \ --bootstrap-server kafka-1:9092 \ --replication-factor 2 --partitions 3执行后可用--describe查看分区与副本分布确认每个分区的 Leader 与副本落在两个不同节点上podman exec kafka-1 /usr/lib/kafka/bin/kafka-topics.sh \ --describe --topic my-topic \ --bootstrap-server kafka-1:90922. 列出全部 Topicpodman exec kafka-1 /usr/lib/kafka/bin/kafka-topics.sh \ --list --bootstrap-server kafka-1:90923. 生产消息以交互模式启动控制台生产者输入任意文本后回车即发送到my-topicpodman exec -it kafka-1 /usr/lib/kafka/bin/kafka-console-producer.sh \ --topic my-topic --bootstrap-server kafka-1:90924. 消费消息刻意从 kafka-2 消费以验证两节点间的复制与负载均衡确实生效。--from-beginning表示从最早的消息开始读取podman exec -it kafka-2 /usr/lib/kafka/bin/kafka-console-consumer.sh \ --topic my-topic --from-beginning --bootstrap-server kafka-2:9092如果生产者输入的消息完整出现在 kafka-2 的消费者输出中说明集群复制链路正常。按CtrlC退出消费者。这套kafka-1 生产、kafka-2 消费的验证方式正是 README.md 中推荐的测试路径。管理命令状态查看、启停与彻底清理查看集群 Broker 列表与 API 版本使用kafka-broker-api-versions.sh可以列出当前集群中的 Broker 及其支持的 API 版本是排查连通性问题的首选命令podman exec kafka-1 /usr/lib/kafka/bin/kafka-broker-api-versions.sh \ --bootstrap-server kafka-1:9092输出中应能看到两个节点的 ID1 和 2及其监听地址同时该命令也可用作 TLS 连接在--command-config中指定客户端属性文件的连通性验证。查看容器运行状态与日志# 查看两个 Kafka 容器的运行状态Up 时长、端口映射等 podman ps | grep kafka # 分别查看两个节点的日志建议配合 tail 定位最近错误 podman logs kafka-1 podman logs kafka-2日志中值得关注的信息包括kafka-storage.sh format的集群 ID 输出、Registered broker提示以及是否有Error级别的连接异常。更多排查建议可参考 README.md 的 Troubleshooting 章节。停止与重新启动集群# 停止全部节点容器保留数据卷保留 podman stop kafka-1 kafka-2 # 再次启动Kafka 会从 meta.properties 恢复集群状态 podman start kafka-1 kafka-2由于数据保存在命名卷中stop/start 循环不会丢失 Topic 与消息数据这也是运维中最常用的重启方式。彻底移除集群podman stop kafka-1 kafka-2 podman rm kafka-1 kafka-2 podman volume rm kafka-1-data kafka-2-data podman network rm kafka-network注意volume rm与network rm会永久删除数据和网络定义属于不可逆操作仅在确认不需要保留数据时执行。若要重新部署删除后再次运行podman-compose up -d即可参见 README.md 的 Quick Start。让客户端接入集群容器内外两种方式容器间访问同网络集群内部的所有服务如 OpenReplay 的 backend、connector 等应使用 Broker 主机名与内部端口bootstrap.serverskafka-1:9092,kafka-2:9092客户端容器必须与 Kafka 容器处于同一 Docker/Podman 网络即kafka-network才能解析kafka-1/kafka-2主机名详见 CONNECTION_GUIDE.md。宿主机访问从宿主机或外部应用连接时使用端口映射后的地址bootstrap.serverslocalhost:9092,localhost:9094其中9092对应 kafka-1、9094对应 kafka-2。若客户端位于宿主机之外的外部网络还需要把KAFKA_ADVERTISED_LISTENERS改为可达的公网 IP/主机名并在防火墙放行对应端口9092/9093/9094/9095这一点同样记录在 CONNECTION_GUIDE.md 的 Network Requirements 一节。按需扩展从基础集群到自定义配置基础集群采用 PLAINTEXT无加密监听器适合开发与联调环境。仓库还提供了两类进阶部署TLS 加密集群运行./generate-certs.sh生成证书后使用podman-compose -f docker-compose-tls.yml up -d启动。TLS 版在 kafka-1 上额外暴露 SSL 端口 9094kafka-2 为 9097并支持KAFKA_SSL_CERT_FILE、KAFKA_SSL_KEY_FILE、KAFKA_SSL_CA_FILE、KAFKA_SSL_CLIENT_AUTH等变量见 docker-compose-tls.yml底层由 start-kafka.sh 自动完成 PEM 证书到 JKS keystore/truststore 的转换自定义参数集群通过podman-compose -f docker-compose-custom.yml up -d启动。所有 Kafka 属性都可通过KAFKA_CFG_前缀注入例如KAFKA_CFG_NUM_NETWORK_THREADS: 8对应num.network.threads8转换规则点变下划线、转大写、加前缀由 start-kafka.sh 统一处理。常见的自定义场景与完整参数对照表记录在 CUSTOM_CONFIG.md 与 CONFIG_REFERENCE.txt 中例如调大消息上限KAFKA_MESSAGE_MAX_BYTES默认 1MB、调整保留策略KAFKA_LOG_RETENTION_HOURS等。常见问题排查现象排查步骤客户端报Connection refused先podman ps \| grep kafka确认容器存活再podman port kafka-1核对端口映射主机名解析失败kafka-1无法解析确认客户端容器与 Kafka 在同一网络外部访问改用localhost 映射端口消息过大MessageSizeTooLargeExceptionBroker 的KAFKA_MESSAGE_MAX_BYTES、Producer 的max.request.size、Consumer 的fetch.max.bytes三处必须同时调大并保持一致配置似乎未生效podman exec kafka-1 cat /tmp/server.properties查看生成的真实配置或podman exec kafka-1 env \| grep KAFKA核对环境变量需要验证 Broker 连通性podman exec kafka-1 /usr/lib/kafka/bin/kafka-broker-api-versions.sh --bootstrap-server kafka-1:9092生产环境部署前还建议对照 README.md 的 Production Checklist 逐项检查使用 CA 签发的证书、开启 TLS 主机名校验、为内部通信启用 SSL、配置合理的消息大小与保留策略、关闭自动建 TopicKAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE: false、接入监控与日志聚合等。小结本文围绕 CLUSTER_INFO.md 完整还原了 OpenReplay 自托管 Kafka 双节点集群的现状与用法两个节点通过共享 Cluster ID 组成 KRaft Quorum节点身份、端口映射与持久化策略定义在 docker-compose.yml启动时由 start-kafka.sh 动态生成服务端配置并完成存储格式化。掌握创建 Topic → 双端生产消费 → 查看集群状态 → 优雅启停这一完整闭环即可在本地复现这套生产可用的 Kafka 环境并进一步向 TLS 加密与自定义参数方向扩展。赞分享可观测性开发工具前端后端【免费下载链接】openreplaySession replay, cobrowsing and product analytics you can self-host. Best for reproducing issues and iterating on your product.项目地址https://gitcode.com/gh_mirrors/op/openreplay点击查看免费下载相关推荐OpenReplay 自托管 Kafka Helm Chart 部署实战KRaft 模式、TLS 加密与生产化配置全指南OpenReplay 自托管 Kafka Helm Chart 部署实战KRaft 模式、TLS 加密与生产化配置全指南 本文以 OpenReplay 仓库中可观测性开发工具前端后端DBX Kafka 4.3 单节点 KRaft 开发环境与 smoke 数据验证指南DBX Kafka 4.3 单节点 KRaft 开发环境与 smoke 数据验证指南 在 DBX 项目的 Database Test Lab 中Kafka 4数据库开发者工具桌面应用CLIMCP 服务AI 应用Cilium 节点连通性体检cilium-health status 命令详解与集群排障实战Cilium 节点连通性体检cilium health status 命令详解与集群排障实战 cilium health status 是 Cilium 自带云原生网络服务网格可观测性网络安全eBPF创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
