You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently KEDA looks for the Pod phase (when scaling strategy is set to accurate) to determine whether a pod is pending or not in order to avoid excess triggers when pod is waiting to start or create. This feature was introduced in #1391.
I believe this could be enhanced by not only looking at the Pod's phase, but also its conditions. The conditions should be configurable like:
Another refactor can be to not look at the Pod's Running phase at all since the native PodScheduled: true condition means the Pod phase is Running so PodScheduled can always be set in customPendingPodConditions (but I'd leave this to whoever implements it)
Use-Case
SQS scaler with a polling interval of 5s (needs to react ASAP to new messages).
Sometimes the pod is already marked with a Running phase but haven't deleted the message from the queue just yet so KEDA triggers another redundant job in the meantime 😢
Using Readiness Probes (or custom readinessGate) would allow me to mark the pod as "not pending" only after assuring the message is no longer in the queue, helping me to avoid those redundant KEDA triggers 💯
Anything else?
Thank you for this great solution. Go KEDA! 🥇
The text was updated successfully, but these errors were encountered:
Proposal
Currently KEDA looks for the Pod phase (when scaling strategy is set to
accurate
) to determine whether a pod is pending or not in order to avoid excess triggers when pod is waiting to start or create. This feature was introduced in #1391.I believe this could be enhanced by not only looking at the Pod's phase, but also its conditions. The conditions should be configurable like:
Another refactor can be to not look at the Pod's
Running
phase at all since the nativePodScheduled: true
condition means the Pod phase isRunning
soPodScheduled
can always be set incustomPendingPodConditions
(but I'd leave this to whoever implements it)Use-Case
SQS scaler with a polling interval of 5s (needs to react ASAP to new messages).
Sometimes the pod is already marked with a
Running
phase but haven't deleted the message from the queue just yet so KEDA triggers another redundant job in the meantime 😢Using Readiness Probes (or custom
readinessGate
) would allow me to mark the pod as "not pending" only after assuring the message is no longer in the queue, helping me to avoid those redundant KEDA triggers 💯Anything else?
Thank you for this great solution. Go KEDA! 🥇
The text was updated successfully, but these errors were encountered: