GKE升级时Strimzi Kafka出现leader broker无匹配监听器报错是否正常

结论 #

你遇到的三类报错属于Kubernetes集群升级触发Kafka滚动重启期间的正常预期现象，升级完成后自动恢复即可判定无异常，无需额外排查故障。

报错原因解释 #

你当前部署的是3副本Kafka集群，配置了内部Topic复制因子为3、最小ISR为2，本身符合高可用部署要求，GKE升级时会逐节点驱逐Pod，Strimzi Operator默认会按滚动策略逐个重启Kafka Pod，过程中出现的报错对应如下场景：

• 客户端报Connection to node X could not be established. Broker may not be available.：对应被重启的Broker Pod处于终止过程中、或重启后尚未完成初始化启动，监听器还未对外暴露，客户端尝试连接该节点自然会失败，属于临时网络不通的中间态。
• 客户端报Partitions have leader brokers without a matching listener：分区Leader选举过程中，新Leader刚被选举出来，但节点的监听器配置还未完成集群元数据同步，客户端拿到的元数据尚未更新，属于选举流程中的临时状态。
• kafka-exporter报In the middle of a leadership election, there is currently no leader for this partition and hence it is unavailable for writes：对应旧Leader已经下线，新Leader选举流程还未完成的空窗期，分区暂时没有可提供服务的Leader，选举完成后会自动恢复。

可选优化建议 #

如果要降低升级过程中的报错量、减少业务侧感知，可以做如下调整：

• 调整Kafka客户端配置：增加合理的重试次数、设置适当的重试间隔，调小metadata.max.age.ms参数让客户端更快同步最新的集群元数据
• 保持当前的高可用配置不变，确保升级过程中不会同时下线2个及以上的Kafka Pod，避免出现ISR不足的情况
• 后续可逐步升级Strimzi Operator与Kafka版本，新版本针对Kubernetes环境下的滚动重启可用性做了大量优化，可进一步缩短中间不可用时间

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