[Question] Question about Knative Consumergroup Replica Logic

[lamluongbinh]

Hi team,

I’d like to ask for some clarification about the replica distribution logic in Knative Eventing (Kafka Broker / Channel).

Context:

• I’ve configured pod_capacity = 20, so the total capacity is 60. My current total replicas is 54.
• I have 3 dispatcher pods, which are enough to handle my ConsumerGroup replicas.
• When I set the ConsumerGroup replicas of a Trigger to 3, I’ve observed several distribution patterns:
  • 1 pod: controls all 3 replicas
  • 2 pods: one pod controls 2 replicas, another controls 1
  • 3 pods: each pod controls 1 replica.

I’d like to understand the difference between these scenarios:

1. If a single pod controls multiple replicas (e.g., all 3 replicas on one pod), does that affect processing speed or parallelism compared to distributing them across multiple pods? In other words, what’s the difference between one pod running a single replica versus the same pod handling three replicas?
2. From reviewing the code, I noticed that the consumerClient is created based on the placement, where one placement maps to one pod. Why doesn’t Knative allow multiple consumers within the same pod to process different workloads or partitions in parallel (different consumerClientID)?
3. What is the current logic for distributing replicas across pods? Is there a mechanism to ensure replicas are evenly spread across dispatcher pods? Can we configure a Trigger with 3 replicas so that they always run on 3 different pods (placements)?

Thanks in advance for your help!

[creydr]

@Cali0707 can you give more insights on this?

/cc @Cali0707

[Cali0707]

Hey - I haven't looked into the details of this much recently. The specific logic should be coming from https://github.com/knative/eventing/tree/main/pkg/scheduler

[lamluongbinh]

Thanks @Cali0707 for your reply. Let me also open a question in the main Eventing project.

• [Question] Question about Knative Consumergroup Replica Logic - xpost knative/eventing#8750