feat: Use informer cache for ReplicaSet replica count lookups

[mattshep]

GetCurrentReplicas() has special handling for Deployments and StatefulSets that uses the controller-runtime client (backed by informer cache) instead of the scale subresource API. This avoids live API calls on every poll.

ReplicaSets were missing this optimization and always used the scale subresource, causing a live API call every polling interval. With many ScaledObjects targeting ReplicaSets, this creates significant API server load.

This change adds ReplicaSet to the list of resource types that use the informer cache, reducing API calls for ReplicaSet-targeted ScaledObjects.

Validated in a staging environment with 67 ScaledObjects targeting ReplicaSets:

• Before: ~767 GET requests/minute to /apis/apps/v1/.../replicasets/.../scale
• After: Dropped to ~128/minute

No unit tests found for existing case statements.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[JorTurFer]

I think that there isn't any way to test this with unit tests, could you tell us something about the use case where you need to scale replicasets directly? We can cover it using e2e tests adding one case where KEDA scales the rs directly, ensuring that this code works

[mattshep]

We run a platform where users deploy workloads that scale based on a Redis queue (pending session requests). When a user pushes a new version, we want the old version to remain independently scalable — for example, to handle traffic surges if the new version is broken.

With Deployment-targeted ScaledObjects, only the current ReplicaSet scales; old ReplicaSets are stuck at their replica count. We create ReplicaSets directly (rather than one Deployment per revision) because ReplicaSets are the natural primitive — Deployments add rollout logic we don't need since we manage revision lifecycle ourselves.

Happy to help with e2e test scenarios if useful.

[JorTurFer]

We run a platform where users deploy workloads that scale based on a Redis queue (pending session requests). When a user pushes a new version, we want the old version to remain independently scalable — for example, to handle traffic surges if the new version is broken.

With Deployment-targeted ScaledObjects, only the current ReplicaSet scales; old ReplicaSets are stuck at their replica count. We create ReplicaSets directly (rather than one Deployment per revision) because ReplicaSets are the natural primitive — Deployments add rollout logic we don't need since we manage revision lifecycle ourselves.

Happy to help with e2e test scenarios if useful.

With this in mind, I'd take some test like https://github.com/kedacore/keda/tree/main/tests/internals/subresource_scale as inspiration and write another specific for replicaset directly. The main goal is to have this new use case covered to avoid breaking it in the future.

Does it make sense?

[JorTurFer]

/run-e2e replicaset
Update: You can check the progress here

[JorTurFer]

/run-e2e replicaset
Update: You can check the progress here