Strimzi Kafka Connect集群资源规划咨询：单/双Worker选择？

核心问题解答 #

对于你的小负载场景（每个连接器仅1个任务），并非必须部署2个Worker：

• 如果业务可以接受Pod故障重建期间的短暂停机（通常几十秒到数分钟），仅部署1个Worker完全可行。因为你的AKS集群有2个专属节点，当Worker所在节点故障时，Kubernetes会自动将Pod调度到另一个可用节点完成重建。
• 但要注意配置Pod反亲和规则，确保故障时Pod能被调度到备用节点，避免因节点亲和限制导致无法重建。

何时需要部署双Worker #

如果符合以下任一场景，建议部署2个及以上Worker：

• 零停机需求：业务不允许数据流动出现任何中断。单Worker故障时，连接器任务会暂停直到Pod重建完成；双Worker模式下，任务会自动转移到存活的Worker节点，实现无中断服务。
• 未来负载扩容预期：即便当前负载小，若后续计划增加连接器数量或任务数，提前部署多Worker可避免后续扩容操作，同时能更好地分摊负载。
• 高SLA要求：若业务对可用性要求严格（如99.9%以上），单Worker的故障重建时间会影响达标；多Worker提供的冗余能力能显著提升整体可用性。

Strimzi Kafka Connect资源规划最佳实践 #

• 基于负载匹配Worker数量：每个Worker的承载能力由CPU、内存资源决定，小负载下1个Worker足够；当任务数超过单Worker的资源上限（如出现CPU/内存持续高占用），再逐步扩容Worker数量。
• 节点分布策略：使用Pod反亲和配置，确保多个Worker分布在不同节点，避免单点故障导致所有Worker不可用。示例配置（Strimzi KafkaConnect CR）：

  spec:
    template:
      pod:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                - key: strimzi.io/name
                  operator: In
                  values:
                  - <your-connect-cluster-name>
              topologyKey: kubernetes.io/hostname
  

• 资源预留与限制：根据连接器类型（如JDBC、CDC连接器）配置合理的CPU/内存请求和限制，避免资源不足导致任务卡顿或OOM。示例：

  spec:
    resources:
      requests:
        cpu: "500m"
        memory: "1Gi"
      limits:
        cpu: "1"
        memory: "2Gi"
  

• 健康检查配置：确保启用Strimzi默认的存活和就绪探针，快速检测Worker异常并触发重建，缩短故障恢复时间。
• 自动伸缩：对于负载波动较大的场景，可结合Kubernetes HPA，基于CPU/内存使用率或自定义指标（如连接器任务队列长度）自动调整Worker数量。
• 分布式模式依赖：Strimzi Kafka Connect默认采用分布式模式，配置存储在Kafka内部主题中，无需额外共享存储，多Worker会自动同步配置和任务状态。

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