Strimzi Kafka Operator在KRaft模式下Pod健康检查失败的排查与解决

问题背景

在使用Strimzi Kafka Operator部署KRaft模式的Kafka集群时，用户遇到了Pod健康检查失败的问题。具体表现为Kafka Pod的Readiness Probe无法连接到localhost:8080端口，导致Pod一直处于未就绪状态。

问题现象

在Kubernetes集群中部署KRaft模式(Controller+Broker组合角色)的Kafka集群后，发现所有Kafka Pod都无法达到Ready状态。通过查看Pod事件和日志，发现以下关键信息：

1. Readiness Probe检查失败，错误信息显示无法连接到localhost的8080端口
2. 日志显示Kafka节点启动过程中无法与控制器仲裁注册
3. 最终导致Broker启动失败并进入关闭流程

根本原因分析

经过深入排查，发现问题主要由以下几个因素导致：

1. 存储配置问题：最初使用的是本地存储卷(Local PV)，可能存在权限或挂载问题，导致Kafka无法正确写入数据
2. 网络连通性问题：KRaft模式下节点间需要稳定的网络通信，若网络配置不当会导致控制器仲裁无法形成
3. 资源限制问题：虽然CPU和内存资源请求配置合理，但在某些环境下仍可能出现资源争用

解决方案

针对上述问题，我们采取了以下解决措施：

1. 改用云提供商存储：将本地存储改为Azure Disk，确保存储的可靠性和性能
2. 优化网络配置：确保Kubernetes集群内Pod间网络畅通，特别是跨节点通信
3. 调整资源配置：适当增加CPU和内存资源限制，避免资源不足导致进程异常

配置示例

以下是经过验证可用的KRaft模式Kafka集群配置示例：

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: kraft
  namespace: kafka
spec:
  replicas: 3
  roles:
    - controller
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        class: managed-premium # 使用Azure Premium Disk

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: kafka-cluster
spec:
  kafka:
    version: 3.8.0
    listeners:
      - name: plain
        port: 9092
        type: internal
      - name: tls
        port: 9093
        type: internal
        tls: true
    config:
      min.insync.replicas: 2
      default.replication.factor: 3
    resources:
      requests:
        cpu: "3"
        memory: "12Gi"
      limits:
        cpu: "4"
        memory: "16Gi"

经验总结

1. 存储选择：在生产环境中，建议使用云提供商提供的持久化存储，而非本地存储
2. 资源监控：即使配置了合理的资源请求，仍需监控实际使用情况，及时调整
3. 日志分析：Kafka启动失败时，应仔细分析完整日志，而非仅关注最后的错误信息
4. 渐进式部署：可以先部署单节点测试，确认无误后再扩展为多节点集群

最佳实践建议

1. 在部署KRaft模式的Kafka集群前，确保底层基础设施(存储、网络)稳定可靠
2. 使用Strimzi提供的健康检查机制，但需要理解其工作原理
3. 对于生产环境，建议进行充分的测试验证
4. 保持Strimzi Operator和Kafka版本的兼容性

通过以上措施，可以有效避免类似问题的发生，确保KRaft模式的Kafka集群稳定运行。