Only resolve PodSpec if needed (lazy resolution)

[alt-dima]

Provide a description of what has been changed

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
• Changelog has been updated and is aligned with our changelog requirements
• 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)

Fixes #

Relates to #

[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]

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

[JorTurFer]

I think that avoid checking not needed fields is always nice, but why would you like to avoid podSpec? Is there any case you're dealing with?

[alt-dima]

I think that avoid checking not needed fields is always nice, but why would you like to avoid podSpec? Is there any case you're dealing with?

Yes! After update from version 2.16.1 to 2.18.1 i noticed a spike in memory usage from 256Mb to 1Gb!
Some details and investigation:
https://kubernetes.slack.com/archives/CKZJ36A5D/p1763483034433569

In our clusters we do not use any fromEnv options. and in biggest clusters 1000s of pods = leads in a lot of api calls to k8s api and keda's memory usage

I would like to understand why/when behaviour changed? Maybe i missed changelog

[JorTurFer]

Gotcha! now makes sense :)
As we are using cached client, I'm not sure if this will solve or even reduce the load as the manifests are already cached and requests are done to the local cache by the client. have you seen memory improvements after this fix?

[alt-dima]

Gotcha! now makes sense :) As we are using cached client, I'm not sure if this will solve or even reduce the load as the manifests are already cached and requests are done to the local cache by the client. have you seen memory improvements after this fix?

Just deployed on staging and i see decrease from 256 to 145 Mb. and also in pprof looks better now (need to solve secrets too :) )
Can't deploy now to prod biggest cluster to verify drop from 1Gb mem usage

And to verify again, deployed non-patched version

[JorTurFer]

nice improvement!

[JorTurFer]

Could you include a record in changelog? I think that under improvements it's nice

[JorTurFer]

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

[JorTurFer]

It looks that unit tests are failing, could you take a look?

[zroubalik]

Nice improvement!

Could you please check failures in unit tests and add Changelog entry?

[alt-dima]

Actually, now i'm not sure that memory usage was caused by this PodSpec.
because in version 2.18.2 it was fixed :/
So it was not related to PodSpec. By ChangeLog 2.18.1->2.18.2 i was unable understand which change/PR fixed memory issue

So maybe this PR is not so relevant

[rickbrouwer]

Given that this PR apparently no longer fixes the memory usage issue, and given @JorTurFer 's comment about using a cached client, is this PR still necessary as an improvement? Is there any benefit to this PR, does it still solve something?

[JorTurFer]

Although the client is cached, requesting items which are not going to be used, increases the memory usage (IIRC, runtime k8s client uses DeepCopy from cached items to ensure consistency), I'm not sure if this makes sense or it's a micro optimization which makes the code harder to understand or really makes sense.

@alt-dima , could you test rebasing your branch with latest dep versions and check if there is any memory reduction from v2.18.2?