vpa-admission-controller: Improve finding the matching VPA for Pod

[ialidzhikov]

What type of PR is this?

/kind bug

What this PR does / why we need it:

As outlined in #6925, right now the logic in the vpa-admission-controller to find the matching VPA for a Pod is expensive/ineffective. In a summary, no matter the given Pod is scaled by VPA or not, the vpa-admission-controller gets all VPAs in the namespace and fetches the selector for every VPA. Fetching the selector for a VPA is an expensive operation when the VPA's targetRef is a custom resource. For such cases, the /scale subresource is being fetched. Note that the used selectorFetcher does not have a cache client-side and it always does a GET request for the /scale subresource:

autoscaler/vertical-pod-autoscaler/pkg/target/fetcher.go

Line 130 in c79bdaf

// TODO: cache response

This PR improves the effectiveness of the operations by using the following steps.

1. Find to the "top most well-known scalable controller" (aka parent contrller) for the Pod
2. Find all VPAs that match the parent controller
3. Fetch the selector (fetch /scale subresource when the targetRef is a CR) only for VPAs which targetRef is matching the parent controller
4. Find the strongest VPA that matches the Pod

In this way the selector would be fetched only for VPAs that match the Pod's parent controller. Previously it was fetched always for all VPAs in the namespace.

In GetControllingVPAForPod func it was always fetching the parent controller for a Pod, hence we are not introducing a change by fetching always the Pod's parent controller at the beginning of the GetMatchingVPA func.

Which issue(s) this PR fixes:

N/A
but a result of the following issues #6925, #6884

Special notes for your reviewer:

Does this PR introduce a user-facing change?

vpa-admission-controller: The logic for finding the matching VPA for Pod is now more effective.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[plkokanov]

Thanks for opening the PR! Just one small comment on my side.

[plkokanov]

Thanks for adding the logs, just some very minor nits.

[adrianmoisey]

Can a test be written for this function?

[ialidzhikov]

I added unit test in dcbd716.

[ialidzhikov]

I am sorry for the delay. I got stuck with other high priority tasks. I will get back to the PR review and address it next week.

[ialidzhikov]

@adrianmoisey @plkokanov @voelzmo I rebased the PR and address review comments! PTAL.

[plkokanov]

lgtm on my side

[adrianmoisey]

I've had a look and I'm also generally happy with it
I'd like to still give it a test run locally

[adrianmoisey]

I gave this a test, seems to work.
I'm unsure how to compare the performance of this change to what it was before hand though.
/lgtm

[kwiesmueller]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ialidzhikov, kwiesmueller, plkokanov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• vertical-pod-autoscaler/OWNERS [kwiesmueller]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment