无法通过KEDA水平自动扩缩容Strimzi KafkaConnect Worker Pod问题

一、修复KEDA ScaledObject无法识别KafkaConnect scale子资源的问题 #

从你提供的错误日志来看，核心矛盾是KEDA判定目标KafkaConnect资源未暴露/scale子资源，但你已确认CRD中包含该定义。可以按以下步骤排查解决：

1. 直接验证KafkaConnect实例的scale子资源可用性
   用kubectl调用scale接口测试实例是否真的支持该子资源：

   kubectl get --raw /apis/kafka.strimzi.io/v1beta2/namespaces/devtest/kafkaconnects/kafka-connect-cluster/scale
   

   若返回包含spec.replicas和status.replicas的JSON结构，说明实例的scale子资源正常；若返回404或错误，需检查KafkaConnect实例配置或Strimzi版本兼容性。

2. 核对ScaledObject的API版本匹配度
   确认你的Strimzi集群实际使用的KafkaConnect API版本：

   kubectl api-resources | grep kafkaconnect
   

   如果输出的API版本不是kafka.strimzi.io/v1beta2，立即修改ScaledObject中scaleTargetRef.apiVersion为实际版本（比如常见的v1beta1）。

3. 检查KEDA Operator的权限配置
   KEDA Operator必须具备对kafkaconnects.kafka.strimzi.io资源的get、update、patch权限。查看KEDA的ClusterRole（通常名为keda-operator）是否包含以下规则：

   - apiGroups: ["kafka.strimzi.io"]
     resources: ["kafkaconnects/scale"]
     verbs: ["get", "update", "patch"]
   

   若缺失，需为KEDA Operator添加该权限。

4. 确认Strimzi版本兼容性
   建议使用Strimzi 0.28及以上版本，旧版本可能存在scale子资源的实现缺陷，导致KEDA无法正常识别。

二、扩缩容后连接器的自动分配逻辑 #

当KafkaConnect集群的Pod数量变化（手动或KEDA自动缩放），Kafka Connect会自动触发集群再平衡：

• 所有Worker节点会重新协商任务分配，将Debezium连接器的CDC任务均匀分发到当前运行的Worker Pod上。
• 整个过程完全自动化，无需手动干预，Strimzi和Kafka Connect会确保任务先迁移再终止Pod，不会导致数据丢失或任务中断。

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