Gradle运行的Kafka集成测试在GitHub Actions环境执行失败问题咨询

关于Ubuntu系统运行容器化Kafka的已知问题 #

Ubuntu本身不存在与容器化Kafka直接冲突的系统性bug，但默认的底层配置差异会导致Kafka首次运行失败的概率远高于MacOS、Fedora等系统，这也是你司同事本地Ubuntu设备也能复现问题的核心原因，常见触发点包括：

• Ubuntu 20.04及以上版本默认启用cgroup v2，你使用的6.2.0版本Confluent Kafka镜像对cgroup v2的资源统计接口适配存在缺陷，会出现健康检查误报通过，但Kafka控制器初始化尚未完成的情况
• Ubuntu默认的iptables/nftables规则在Docker桥接网络场景下，首次启动容器时会出现1-2分钟的端口转发延迟，同一网络下的服务无法正常访问Kafka端口
• CI环境普遍配置偏低，Ubuntu默认的ext4文件系统writeback缓存策略会导致Kafka首次写入元数据时刷盘超时，元数据主题创建失败，第二次启动时因为缓存已有数据所以恢复正常

本次异常的可能诱因 #

结合你给出的配置和复现特征，核心原因是Kafka健康检查逻辑存在漏洞，加上Ubuntu的网络特性，导致测试启动时Kafka实际未完全就绪：

1. 你当前使用的Kafka健康检查命令kafka-topics --bootstrap-server 127.0.0.1:9092 --list仅能验证Kafka端口已启动，无法证明控制器已完成主题创建、副本分配的全流程初始化。首次启动时健康检查误报通过，代码发送消息时Kafka还未完成自动创建主题的逻辑，消息直接被丢弃，所以record-send-total指标一直返回0
2. 第二次执行测试恢复正常，是因为第一次运行的等待间隙Kafka已经完成了全部初始化流程，后续消息发送无阻碍
3. 你预先创建主题、发送测试消息的操作未生效，是因为操作执行时Kafka控制器仍未就绪，创建请求被挂起，测试启动时流程仍未完成

可选修复方案 #

• 替换Kafka健康检查命令为更严谨的逻辑：kafka-broker-api-versions --bootstrap-server 127.0.0.1:9092 | grep -q "Produce"，该命令会验证Kafka的生产消息接口已完全可用
• 在docker-compose up -d执行完成后、集成测试启动前，新增等待逻辑：手动向测试主题发送一条测试消息，确认消费成功后再启动测试
• 如果你使用的是Ubuntu 20.04及以上版本的自托管Runner，可以在Docker启动参数中添加systemd.unified_cgroup_hierarchy=0切换到cgroup v1，规避镜像适配问题

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