Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 'startThreshold' for queue scalers like Kafka #692

Closed
kellybirr opened this issue Mar 20, 2020 · 10 comments
Closed

Support 'startThreshold' for queue scalers like Kafka #692

kellybirr opened this issue Mar 20, 2020 · 10 comments
Labels
feature-request All issues for new features that have not been committed to needs-discussion stale All issues that are marked as stale due to inactivity

Comments

@kellybirr
Copy link

kellybirr commented Mar 20, 2020

When using queue based scalers like EventHubs, Kafka, RabbitMQ it would be great to have a low threshold (of 1 message) when the HPA has scaled to zero, but keep the normal, larger lagThreshold when scaling up above one instance.

I'm mostly talking about Kafka a the moment, as that's what I use. I'd like to let my ScaledObject drop to zero for topics that don't see much traffic and start when a single message needs processing. However, I only want to scale one instance per 100 messages behind the head of the topic. This is especially useful when messages come infrequently but in batches when they do.

Something like this:

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: my-kafka-processor-keda
spec:
  scaleTargetRef:
    deploymentName: my-kafka-processor
  pollingInterval: 30
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: awesome.servicebus.windows.net:9093
      consumerGroup: my-kafka-worker
      topic: my-topic
      lagThreshold: "100"
      startThreshold: "1"

I think for this to work, the scaler would have to lie to the HPA about the metric value when it was greater or equal to the startThreshold but less than the lagThreshold and claim that it was the lagThreshold, or reconfigure the HPA when it scaled to zero and then back when scaled above zero.

@kellybirr kellybirr added feature-request All issues for new features that have not been committed to needs-discussion labels Mar 20, 2020
@tomkerkhove
Copy link
Member

Interesting. Question is, should 1 be configurable or just how it behaves because AFAIK it was spinning up an instance once there is a message already; no @jeffhollan ?

@kellybirr
Copy link
Author

One, as the default, would be ideal. I’m pretty sure that’s what 99% if use cases would call for. Being able to configure it to wait for more than one would be a benefit in some special cases.

@zroubalik
Copy link
Member

zroubalik commented Mar 20, 2020

I like this idea to enable this option (keeping the default as it is currently of course).

@ppatierno WDYT?

@jeffhollan jeffhollan added this to the v2.0 milestone Apr 16, 2020
@jeffhollan jeffhollan added help wanted Looking for support from community and removed help wanted Looking for support from community labels Apr 16, 2020
@zroubalik zroubalik removed this from the v2.0 milestone Oct 15, 2020
@shashiik
Copy link

#1303 @zroubalik In response to our standup discussion yesterday, this is what I had to accomplish the minimumThreshold requirement.

@knepe
Copy link

knepe commented Nov 2, 2020

+1 on this feature. It would be a great improvement I think 👍

@zroubalik
Copy link
Member

Discussed this with @knepe and he is willing to contribute this for Rabbit MQ scaler 🎉

We will do the POC on Kafka and then follow up with other scalers.

@stale
Copy link

stale bot commented Oct 14, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Oct 14, 2021
@tomkerkhove
Copy link
Member

Is this still WIP @knepe ?

@stale stale bot removed the stale All issues that are marked as stale due to inactivity label Oct 14, 2021
@stale
Copy link

stale bot commented Dec 13, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Dec 13, 2021
@stale
Copy link

stale bot commented Dec 20, 2021

This issue has been automatically closed due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request All issues for new features that have not been committed to needs-discussion stale All issues that are marked as stale due to inactivity
Projects
Archived in project
Development

No branches or pull requests

6 participants