GKE上Strimzi Kafka对接Dataproc Spark流处理报TimeoutException异常

你碰到的TimeoutException: Timeout of 60000ms expired before the position for partition syslog.ueba-us4.v1.versa.demo2-1 could be determined报错，本质是Spark executor在默认60s的超时窗口内，没能成功拿到目标Kafka分区的消费起始位点，任务反复失败重试会消耗大量计算资源，直接拖慢整个流作业的处理性能。结合你GKE部署Strimzi Kafka、Dataproc跑Spark Structured Streaming的架构，这个问题基本逃不开四类原因：网络不通、Kafka分区异常、Spark配置不合理、鉴权失败。

按优先级从高到低排查即可：

• 先查网络连通性：从Dataproc集群的任意工作节点上，直接telnet测试Strimzi Kafka所有Broker节点的服务端口（默认9092，如果你自定义了外部端口就用对应端口），重点确认两点：一是GKE的网络策略、VPC防火墙有没有放通Dataproc网段到Kafka Broker的入站流量；二是Strimzi配置的advertised.listeners地址，必须是Dataproc节点能正常解析、访问的地址，不能只配K8s集群内部的域名，否则跨网络访问必然超时。
• 再查Kafka分区状态：进Strimzi Kafka的Pod用自带的命令行工具执行kafka-topics.sh --describe --topic syslog.ueba-us4.v1.versa.demo2，看报错的-1分区是不是存在Leader副本离线、ISR列表不全、副本同步严重滞后的情况——如果这个分区的Leader刚好在宕机、重启的Broker上，客户端根本连不上对应节点拿位点，必然触发超时。
• 然后查Spark配置和资源：看作业是不是配置了从非常早的位点开始消费，首次启动要拉取的offset范围过大；同时看executor的CPU、内存配的够不够，有没有频繁Full GC导致进程卡几十秒的情况，进程卡顿时根本发不出Kafka请求，自然会超时。
• 最后查鉴权配置：如果你的Strimzi Kafka开了SASL/SSL认证，检查Spark侧配的证书、账号密码是不是正确，鉴权失败的重试流程很容易耗光60s的超时窗口。

对应排查到的原因直接处理即可：

• 网络问题：修改Strimzi Kafka的CR配置，给外部访问监听器配置VPC内可正常解析的内网IP/域名，同步调整防火墙规则放通Dataproc到Kafka所有Broker的端口流量，跨可用区部署的话尽量把Dataproc和Kafka节点放到同一可用区，降低网络延迟。
• Kafka集群问题：如果是分区Leader离线，先重启异常Broker恢复副本同步，副本滞后严重的话手动执行副本重分配，保证每个分区的Leader正常对外提供服务；如果是Broker负载太高请求排队，直接扩容Broker节点分摊压力。
• Spark配置调优：
  1. 先拉长超时窗口，在Spark读Kafka的配置项里加两个参数：kafka.consumer.request.timeout.ms=120000、kafka.default.api.timeout.ms=120000，把默认60s超时改成120s，适配跨集群访问的正常网络延迟
  2. 如果是首次消费要拉取大量历史数据，配置maxOffsetsPerTrigger参数限制单批次拉取的最大offset数，降低首次位点查询的压力
  3. 给executor配足够的CPU和内存，优化GC参数减少长停顿，避免executor本身卡顿导致请求发不出去
• 鉴权问题：把正确的SSL证书、SASL认证配置同步到所有Dataproc工作节点可访问的路径，在Spark Kafka配置里补全对应鉴权参数，避免无意义的鉴权重试。

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