-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP-4943 #4947
base: master
Are you sure you want to change the base?
KEP-4943 #4947
Conversation
bernot-dev
commented
Nov 4, 2024
•
edited
Loading
edited
- One-line PR description: Adding new KEP
- Issue link: Vertical Pod Autoscaling for Workloads with Heterogeneous Resource Requirements #4943
- Other comments:
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: bernot-dev 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 |
Hi @bernot-dev. 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. |
I know this is very much still in draft, but I thought I'd ask now. Does this work depend on in-place pod resizing? |
@adrianmoisey This does not depend on in-place pod resizing any more than existing VPA. However, it will benefit from it when that feature lands. |
This is super cool! I think this could definitely tackle a gap that has existed in vertically scaling daemon sets. Some questions from me:
(Feel free to also tell me to wait until this is captured in the KEP :), I realize this is still a draft proposal!) |
@raywainman Thanks for the questions! These are closely aligned with the first questions I am looking to tackle as I start filling in the details. I am going to be looking for ways to leverage existing code to whatever extent makes sense. I will have to make myself a bit more familiar with existing code before I can find those opportunities. I'm hoping to sidestep the question of, "What do we do about new pods being added to the daemonset?" Retaining existing behavior seems to be the best way forward for now. I can imagine reasonable arguments for a variety of behaviors in different situations. Perhaps it could become configurable in the future, but I would rather keep that out of scope for now. |
Good to know. I know I may be jumping the gun here, so apologies for that, I know you are still working on the KEP. The reason I asked about in-place is because I just assumed the solution you would use, so let me take a step back. At the moment VPA admission-controller receives a Pod before it's scheduled to a node (to my understanding, please correct me if I am wrong), meaning that the VPA admission-controller won't know which node a specific Pod will land on. EDIT: I'm entirely wrong! Turns out that DaemonSets use node affinity to tell the scheduler where to schedule a Pod. I didn't know that! So I guess that's the answer, the node can be fetched from there. SECOND EDIT: What about other workloads, besides DaemonSets? |