Skip to content
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

Questions on AEP-4016: Support for in place updates in VPA #7722

Open
maxcao13 opened this issue Jan 17, 2025 · 1 comment
Open

Questions on AEP-4016: Support for in place updates in VPA #7722

maxcao13 opened this issue Jan 17, 2025 · 1 comment

Comments

@maxcao13
Copy link

maxcao13 commented Jan 17, 2025

Which component are you using?:
/area vertical-pod-autoscaler

Now that support for feature gated InPlacePodVerticalScaling has almost reached Beta graduation in the kubernetes API, it draws nearer that the details of AEP-4016 should be clear, since early development has already started in implementing the AEP and bringing the in-place updates to the VPA: #7673

There are some questions I still have about the AEP, namely about disruptionless/disruptive updates.

InPlaceOnly and InPlaceOrRecreate will attempt to apply a disruption-free update in place if it meets at least one of the following conditions:

  • Quick OOM,
  • Outside recommended range,
  • Significant change.

InPlaceOnly and InPlaceOrRecreate will attempt to apply updates that are not disruption-free in place under the same conditions that apply to updates in the Recreate mode.

Since the conditions are different for both types of actuation, how can we actually make sure the first set of actions will actually be disruption free? I think this problem requires the need for a third resizePolicy MustNotRestart as mentioned in the AEP. However, I asked in the sig-node-inplace-pod-resize slack channel about the possibility of this, and it seems it is impossible for now from a response from Vinay:

Since the actuation of container resize is handled by the container runtime, there's no way to guarantee that the runtime won't restart the container in the context of a resize request.

There is also no way ahead of time to know if your resize request will cause a container restart either.

I believe causes some problems about the AEP-4016 details, as there is only best-effort disrupionless updates. If I am understanding correctly, we should always assume worst case disruptive updates, meaning we will have to apply in-place updates only under the same conditions that apply in Recreate mode, and that this requires amendment to the AEP.

Please let me know if I assuming incorrectly, or if there are any thoughts on this.

@adrianmoisey
Copy link
Member

/area vertical-pod-autoscaler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants