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

fix: unnecessary HPA updates when cpu utilization trigger is used #5822

Closed
wants to merge 2 commits into from

Conversation

uucloud
Copy link

@uucloud uucloud commented May 23, 2024

To address the issue of continuous updates triggered by discrepancies between the ScaledObject and Kubernetes HPA v2 when using CPU utilization triggers, I have implemented a logic similar to the conversion logic used for HPA v1.

This change ensures that the handling of CPU utilization triggers is consistent and prevents the KEDA operator from continuously detecting differences and updating the HPA. The solution mimics the behavior observed when converting HPA v1, thus maintaining stability and expected behavior within the system.

However, this change may cause discrepancies in the latest version (Kubernetes version >= 1.27) of ScaledObject compared to user expectations. Specifically, when users configure CPU utilization triggers, the generated HPA places the CPU utilization metric last. If multiple CPU utilization triggers are configured, only the first one will take effect.

Checklist

Fixes #5821

@uucloud uucloud requested a review from a team as a code owner May 23, 2024 08:49
Copy link
Member

@zroubalik zroubalik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the same applies to memory scaler? Do you think we can add some unit test? Also, could you please add changelog entry? (Improvements section)

Thanks for the contribution!

controllers/keda/hpa.go Show resolved Hide resolved
@uucloud
Copy link
Author

uucloud commented Jul 17, 2024

Does the same applies to memory scaler?

Memory scaler will not have its order altered because HPA v1 only supports CPU utilization. Only CPU utilization metrics are stored separately, causing the order discrepancy.

Do you think we can add some unit test?

I have added the unit tests as requested.

could you please add changelog entry?

Sure, I will add the changelog entry.

@uucloud uucloud force-pushed the main branch 3 times, most recently from 316300f to 174bceb Compare July 17, 2024 07:18
Copy link

stale bot commented Sep 22, 2024

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 Sep 22, 2024
Copy link

stale bot commented Oct 2, 2024

This issue has been automatically closed due to inactivity.

@stale stale bot closed this Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale All issues that are marked as stale due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Continuous HPA updates with CPU Utilization trigger
2 participants