-
Notifications
You must be signed in to change notification settings - Fork 4.2k
AEP-8459: MemoryPerCPU Enforce #8459
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
base: master
Are you sure you want to change the base?
Conversation
Hi @Jrmy2402. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Jrmy2402 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
d7748f1
to
4ca0ab5
Compare
4ca0ab5
to
61e4f32
Compare
/ok-to-test |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! some notes from me
vertical-pod-autoscaler/enhancements/8459-memory-per-cpu/README.md
Outdated
Show resolved
Hide resolved
vertical-pod-autoscaler/enhancements/8459-memory-per-cpu/README.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM with minor comments
/retitle AEP-8459: MemoryPerCPU Enforce |
c5bbed0
to
f4b20b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good we just need to address this https://github.com/kubernetes/autoscaler/pull/8459/files#r2295957092
vertical-pod-autoscaler/enhancements/8459-memory-per-cpu/README.md
Outdated
Show resolved
Hide resolved
/label api-review |
|
||
### Behavior | ||
|
||
* If both CPU and memory are controlled, VPA enforces the ratio. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if both (cpu and memory) are not specified? Should that be a validation error? It seems, like we should enforce that if you specify both you should get an error, this way we'll ensure that either you specify all the pieces of the puzzle, or none.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially, my thinking was to simply ignore memoryPerCPU if either CPU or memory was not specified in controlledResources.
But if the philosophy is rather to fail fast and return a validation error whenever memoryPerCPU is set without both CPU and memory being present, I’m fine with that approach too, I can update the AEP accordingly.
* Applies to Target, LowerBound, UpperBound, and UncappedTarget. | ||
* Ratio enforcement is strict: | ||
* If the memory recommendation would exceed `cpu * memoryPerCPU`, then **CPU is increased** to satisfy the ratio. | ||
* If the CPU recommendation would exceed `memory / memoryPerCPU`, then **memory is increased** to satisfy the ratio. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to say we should error out if the math doesn't stand with the cpu and memory values, adjusting seems "magical", and I'd advice against it. Explicitness is always better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point, implicit adjustments can indeed feel “magical.”
In this case, though, the whole purpose of the feature is to enforce the ratio automatically: if CPU or memory drifts away from the configured ratio, VPA brings them back in line.
If we only validated and errored, users wouldn’t get the behavior they’re asking for (“always keep memory = cpu × memoryPerCPU”), they’d just see failures.
That would make the feature much less useful in practice.
Or maybe I didn’t fully understand your point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're talking about two distinct things 😅 I was more asking about the validation case, where we ensure that the provided memory and cpu ensure we can reach the configured memoryPerCPU
. Iow. if I specify cpu=1, memory=4Gi
and use memoryPerCPU=5
then the math won't work and that should fail validation, but cpu=1, memory=4Gi
and memoryPerCPU=3
will work, b/c that's achievable.
Whereas you're talking about the actual enforcement, which indeed will be "magical" 😉, and that's totally fine.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, we were talking about two different layers.
I’ve pushed a commit to clarify the validation side: 93d9437
vertical-pod-autoscaler/enhancements/8459-memory-per-cpu/README.md
Outdated
Show resolved
Hide resolved
Hi, @soltysh, Did you check my answers to your comments? Thanks in advance |
Hi, @omerap12, @adrianmoisey do you think it could be merged as it is today, or do you have some comments? Thanks in advance |
We can't merge this until a Kubernetes api reviewer |
/release-note-none |
/label tide/merge-method-squash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From API perspective this seems good, my comments are non-blocking, but mostly clarifying.
* Applies to Target, LowerBound, UpperBound, and UncappedTarget. | ||
* Ratio enforcement is strict: | ||
* If the memory recommendation would exceed `cpu * memoryPerCPU`, then **CPU is increased** to satisfy the ratio. | ||
* If the CPU recommendation would exceed `memory / memoryPerCPU`, then **memory is increased** to satisfy the ratio. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're talking about two distinct things 😅 I was more asking about the validation case, where we ensure that the provided memory and cpu ensure we can reach the configured memoryPerCPU
. Iow. if I specify cpu=1, memory=4Gi
and use memoryPerCPU=5
then the math won't work and that should fail validation, but cpu=1, memory=4Gi
and memoryPerCPU=3
will work, b/c that's achievable.
Whereas you're talking about the actual enforcement, which indeed will be "magical" 😉, and that's totally fine.
Does that make sense?
Thanks @soltysh, @omerap12, @adrianmoisey, @jackfrancis for the review. |
Thanks! nothing blocking from my end. |
* Example 3: `memoryPerCPU = 4Gi`, with `--container-recommendation-max-allowed-memory=7Gi` or with `maxAllowed.memory=6Gi` set in VPA object | ||
* Baseline recommendation: 2 CPUs, 4Gi memory | ||
* UncappedTarget (ratio enforced): 2 CPUs, 8Gi | ||
* Target (capped): 2 CPUs, 7Gi ← memory capped by max-allowed-memory; ratio not fully satisfied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure if this is a typo or if I'm not understanding something, but surely the Target on this one would be 2 CPUs, 6Gi memory, since maxAllowed.memory
is 6Gi?
* Admission ensures the provided `CPU` and `memory` bounds make the configured `memoryPerCPU` reachable—there must exist at least one (`cpu`, `memory`) such that `memory = cpu × memoryPerCPU`, otherwise the object is rejected. | ||
* Example: with cpu=1 and memory=4Gi, memoryPerCPU=5Gi is invalid (1×5Gi > 4Gi), while memoryPerCPU=3Gi is valid (1×3Gi ≤ 4Gi). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is cpu and memory referring to here? Is this on Pod admission or is this the minAllowed/maxAllowed in the VPA spec?
What type of PR is this?
/kind documentation
/kind feature
/kind api-change
What this PR does / why we need it:
AEP for #8420