You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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: #7673There are some questions I still have about the AEP, namely about disruptionless/disruptive updates.
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: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.
The text was updated successfully, but these errors were encountered: