K8s环境KRaft模式Kafka升级至3.9.0/4.0.0时卡在Metadata Loader追赶阶段

问题核心现象 #

从3.7.2升级到3.9.0或4.0.0时，控制器节点出现两类关键异常日志：

1. 无法建立到localhost/127.0.0.1:9093（节点ID -2）的连接
2. MetadataLoader持续输出still catching up because we still don't know the high water mark yet，无法完成初始化

切回3.7.2镜像后控制器可正常启动，说明元数据未损坏，问题出在新版本的配置或网络兼容性层面。

可能原因及对应解决措施 #

1. 控制器网络监听配置错误 #

新版本KRaft镜像可能默认使用localhost作为监听地址，但K8s集群中控制器Pod需要通过集群内部IP/Service地址通信，导致跨节点连接失败。

• 解决：强制指定listeners和advertised.listeners配置，确保CONTROLLER监听器的地址为集群可访问地址：

  listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
  advertised.listeners=PLAINTEXT://<pod-ip>:9092,CONTROLLER://<pod-hostname>.<headless-service-name>:9093
  listener.security.protocol.map=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
  inter.broker.listener.name=PLAINTEXT
  controller.listener.names=CONTROLLER
  

  替换<pod-hostname>.<headless-service-name>为控制器Pod在K8s headless服务中的FQDN，确保其他控制器节点能解析到。

2. Controller Quorum Voters配置使用localhost #

如果controller.quorum.voters配置中使用localhost作为节点地址，新版本KRaft无法正确解析集群内其他控制器节点，导致无法建立Quorum连接。

• 解决：更新controller.quorum.voters为集群内可访问的节点地址：

  controller.quorum.voters=1@kafka-controller-0.kafka-controller-headless:9093,2@kafka-controller-1.kafka-controller-headless:9093,3@kafka-controller-2.kafka-controller-headless:9093
  

  替换为实际的控制器Pod hostname和headless服务名称。

3. K8s Service/端口映射配置缺失 #

控制器的Raft通信端口（默认9093）未在Pod或headless Service中正确暴露，导致节点间无法通信。

• 解决：
  • 检查控制器Pod的ports配置，确保包含9093端口暴露：

    ports:
    - containerPort: 9093
      name: controller
      protocol: TCP
    

  • 确认headless Service的ports配置包含9093端口，且selector正确匹配控制器Pod标签。

4. 新版本镜像的文件权限问题 #

部分新版本Kafka镜像修改了运行用户的UID/GID，导致无法读取PV中存储的旧元数据文件，进而无法加载高水位信息。

• 解决：
  • 检查PV挂载目录权限，确保Kafka运行用户（通常为UID 1001）有读写权限：

    kubectl exec -it <controller-pod-name> -- ls -ld /var/lib/kafka/data
    

  • 若权限不符，通过initContainer调整目录权限：

    initContainers:
    - name: fix-permissions
      image: busybox:1.36
      command: ["chown", "-R", "1001:1001", "/var/lib/kafka/data"]
      volumeMounts:
      - name: kafka-data
        mountPath: /var/lib/kafka/data
    

5. 跨大版本升级的过渡要求 #

从3.7.2直接跳升到4.0.0可能跨越多个关键版本，部分元数据逻辑或配置要求未满足。

• 解决：先升级到3.8.x版本（如3.8.2），确认集群稳定后再升级到3.9.0或4.0.0，遵循官方推荐的小版本递进升级路径。

验证步骤 #

1. 先升级单个控制器节点，观察日志是否仍出现连接错误和高水位卡滞
2. 若单个节点启动正常，再逐步升级剩余控制器节点
3. 控制器集群稳定后，再开始升级Broker节点

内容的提问来源于stack exchange，提问作者Mr T.