I'm curious to see what this would look like, as I'm a little sceptical if it's going to be better than what we currently have

Why do you feel that way? I think using CEL is an improvement over our current approach.. It aligns with Kubernetes best practices and enables earlier validation in the request flow.

We can also remove large chunks of code which is an idea I always appreciate

My understanding for the need for Validating Admission Policy is to allow users to do validation without having to run infrastructure to do that validation, since it can happen inside the api-server. Ie: https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/3488-cel-admission-control/README.md#motivation

Since we have to be running a a pod to receive webhooks, it means the value of a Validating Admission Policy is decreased slightly.

Obviously a project like the VPA can benefit from a few of the other advantages, such as less network calls.

We can also remove large chunks of code which is an idea I always appreciate

My assumption is that we would be replacing Go code with CEL code. I'm not sure if that will be better or worse.

I had an idea for MutatingAdmissionPolicies... I'm unsure if this idea if good, but hear me out.

Instead of the VPA webhook pod receiving webhooks, making a decision, and returning the response... what if a VPA pod were to write MutatingAdmissionPolicies to the API server, and keep those MutatingAdmissionPolicies updated as the recommendations change?
This was the webhook pod is not in the critical path of pods being created. I don't know if all the VPA features are possible (such as the limit/request ratio that is maintained), but may be this is worth exploring at some stage?

I had an idea for MutatingAdmissionPolicies... I'm unsure if this idea if good, but hear me out.

Instead of the VPA webhook pod receiving webhooks, making a decision, and returning the response... what if a VPA pod were to write MutatingAdmissionPolicies to the API server, and keep those MutatingAdmissionPolicies updated as the recommendations change? This was the webhook pod is not in the critical path of pods being created. I don't know if all the VPA features are possible (such as the limit/request ratio that is maintained), but may be this is worth exploring at some stage?

This might be an interesting way to simplify things for the future, especially given that MutatingAdmissionPolicies can get their configuration from custom resources – this way we could always just replace the currently set requests with the information from the VPA status target.

Currently, however, this feature is alpha in k8s 1.32, there's still some way to go until we can make this a first-class thing in VPA.

I agree. This has potential, but we shouldn't support it as long as MutatingAdmissionPolicies remain in Alpha.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

I don't follow this part:

This was the webhook pod is not in the critical path of pods being created. I don't know if all the VPA features are possible (such as the limit/request ratio that is maintained), but may be this is worth exploring at some stage?

Doesn't the webhook need to run in the critical path of pods being created so that it can adjust resources? Or is this proposing that the admission-controller gets out of the way of pods that are NOT controlled by VPA?

Also on this overall proposal - I'm all for standardizing this stuff to align with best practices. Using this seems like a nice way to simplify things in the admission-controller.

I don't follow this part:

This was the webhook pod is not in the critical path of pods being created. I don't know if all the VPA features are possible (such as the limit/request ratio that is maintained), but may be this is worth exploring at some stage?

Doesn't the webhook need to run in the critical path of pods being created so that it can adjust resources? Or is this proposing that the admission-controller gets out of the way of pods that are NOT controlled by VPA?

Sorry, the English in that sentence wasn't very good.

I had a not-very-well-though-out-idea, that in theory the webhook pod could be removed from the critical path and be replaced with a CEL rule. May be (if possible) the recommender could create a rule (and update those rules as the recommendations change) that has enough logic in it to replace what the admission-controller pod does.

I highly doubt that this would work, but thought I'd write down the idea.