Kafka集群从3.2.3升级至3.3.1后节点无法互联问题求助

问题现象 #

我们正尝试将带有ZK的3节点Kafka集群从3.2.3版本升级至3.3.1版本。使用新二进制文件启动Broker后，3个Broker无法互相连接，相关日志及异常如下：

Broker重复输出的DEBUG日志 #

DEBUG [BrokerToControllerChannelManager broker=1 name=forwarding]: Controller isn't cached, looking for local metadata changes (kafka.server.BrokerToControllerRequestThread)
DEBUG [BrokerToControllerChannelManager broker=1 name=forwarding]: No controller defined in metadata cache, retrying after backoff (kafka.server.BrokerToControllerRequestThread)

SSL配置警告 #

WARN Broker configuration 'ssl.client.auth' is applied only to SSL listeners. Listener-prefixed configuration can be used to enable SSL client authentication for SASL_SSL listeners. In future releases, broker-wide option without listener prefix may be applied to SASL_SSL listeners as well. All configuration options intended for specific listeners should be listener-prefixed. (org.apache.kafka.common.network.ChannelBuilders)

控制器（Broker3）抛出的异常 #

java.io.IOException: Connection to 1 was disconnected before the response was read

故障Broker（Broker1）认证后立即断开连接的日志 #

DEBUG Successfully authenticate User=kafkaadm (org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslServer)
DEBUG Authentication complete; session max lifetime from broker config=0 ms, credential expiration=Tue Jan 20 12:41:53 CET 1970 (-1682029722224 ms); session expiration = Wed May 10 12:10:35 CEST 2023 (0 ms), sending 0 ms to client (org.apache.kafka.common.security.authenticator.SaslServerAuthenticator)
DEBUG [SocketServer listenerType=ZK_BROKER, nodeId=1] Successfully authenticated with /10.49.38.230 (org.apache.kafka.common.network.Selector)
DEBUG Disconnecting expired channel: org.apache.kafka.common.network.KafkaChannel@99aa9bfb id=10.49.37.104:9092-10.49.38.230:46282-0 : RequestHeader(apiKey=UPDATE_METADATA, apiVersion=7, clientId=3, correlationId=2) (kafka.network.Processor)

已尝试但无效的操作 #

• 在所有Broker的server.properties和zookeeper.properties中设置会话超时
• 修改SSL认证配置
• 更换证书
• 一次性升级所有Broker
• 使用旧版ZK搭配新版Kafka

解决方案建议 #

1. 修复SASL会话生命周期配置 #

从Broker1的日志可见会话最大生命周期被设为0ms，这是认证后立即断开的核心原因。Kafka 3.3.x对SASL会话生命周期的处理逻辑有调整，需针对性配置：

• 添加或修改监听器级别的会话生命周期参数：listener.name.<你的监听器名称>.oauthbearer.sasl.server.session.lifetime.ms，设置合理值（例如86400000即24小时）
• 检查全局配置，避免存在覆盖该参数的错误设置，确保不会出现0值

2. 修正SSL客户端认证配置 #

针对SSL警告，将全局ssl.client.auth替换为监听器前缀的配置，例如使用SASL_SSL监听器时，设置：

listener.name.sasl_ssl.ssl.client.auth=required

（根据实际监听器名称调整，确保配置仅作用于对应类型的监听器）

3. 统一Broker间监听器配置 #

确认所有Broker的listeners、advertised.listeners配置完全一致，包括协议类型（SASL_SSL/SSL）、端口、地址，避免因监听器不匹配导致连接失败。

4. 采用滚动升级方式 #

先升级单个Broker，待其正常加入集群并完成元数据同步后，再依次升级剩余Broker，避免全量升级引发的集群状态混乱。

5. 核对OAuthBearer认证配置完整性 #

如果使用OAuthBearer认证，确保所有Broker的以下配置正确：

• sasl.enabled.mechanisms包含OAUTHBEARER
• listener.name.<你的监听器名称>.oauthbearer.sasl.server.callback.handler.class配置了正确的回调处理器
• 验证token有效期逻辑，解决日志中出现的1970年过期时间异常问题（通常是token解析或配置错误导致）

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