GitHub Actions中无法运行Spring Boot Kafka Avro的Testcontainers测试

问题概况 #

本地环境下，使用Testcontainers测试Spring Boot Kafka Avro功能完全正常，但在GitHub Actions执行构建时测试失败，错误核心指向KafkaContainer的withKraft()方法。

关键报错 #

java.lang.ExceptionInInializerError at NativeConstructorAcessorImple.java: -2
Caused by: org.testcontainers.containers.ContainerFetchException at TestContainer.java:56
caused by com.github.dockerjava.api.exception.InternalServerErrorException at DefaultInvocationBuilder.java:247

关联代码片段 #

private static final KafkaContainer KAFKA =
            new KafkaContainer(KAFKA_IMAGE)
                    .withNetwork(KAFKA_NETWORK)
                    .withKraft() // 报错指向此行
                    .withEnv("KAFKA_TRANSACTION_STATE_LOG_MIN_ISR", "1")
                    .withEnv("KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR", "1");

根本原因 #

1. GitHub Actions Runner资源不足
   默认的GitHub Actions Ubuntu Runner仅配备2核CPU、7GB内存，而Kafka Kraft模式启动时需要初始化控制器节点、元数据存储等组件，对CPU和内存的需求高于旧版ZooKeeper模式。资源不足会导致Docker容器内部进程启动超时或崩溃，最终抛出InternalServerErrorException。

2. Kraft模式默认配置未适配低资源环境
   Testcontainers的KafkaContainer启用Kraft时，默认的控制器数量、元数据副本数等配置未针对低资源场景优化，在Runner有限资源下，容器无法完成初始化流程。即便手动设置了事务日志的副本数和ISR，核心的Kraft控制器配置仍可能过高。

3. 容器启动逻辑存在时序问题
   静态代码块中先启动Kafka容器，再为Schema Registry配置Kafka关联并启动，这种顺序会导致Kafka容器在未完全就绪时就承受Schema Registry的连接请求，加重启动压力；另外，容器启动后再设置SCHEMA_REGISTRY_LISTENERS环境变量完全无效，会导致Schema Registry启动异常，间接影响Kafka容器的稳定性。

4. 镜像拉取或Docker权限问题
   GitHub Actions环境中，Docker镜像拉取可能因网络波动出现部分文件损坏，或者Runner的Docker守护进程权限不足，导致容器创建时出现内部错误。不过结合报错精准指向withKraft()，资源和配置适配问题的概率更高。

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