-
Notifications
You must be signed in to change notification settings - Fork 40
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
Explore concept of VNA - Vertical Node Autoscaler #354
Comments
I could see it being useful - though we just use multiple IGs right now with |
@backjo interesting, so you keep multiple IG on min 0, and in case you need to scale up beyond max of ASG-1 - ASG-2..N. would scale up additional nodes for you? How does CA know which ASG to scale? |
More like - we have multiple IGs with different compute / memory requirements. CA is configured to |
In some cases, it may be appropriate to scale nodes vertically, i.e. from m5.xlarge to m5.2xlarge.
For example, when we detect better binpacking may occur, or when the IG reaches the max and there are pending pods.
e.g.
We can try to abstract instance type completely, example:
Initially spin up m5.xlarge (if instanceFamily is provided, otherwise we can decide the best match) which provides 2vcpu/8Gi mem, and we can scale up to m5.4xlarge which has 16/64 respectively.
Another option is to keep this new spec inside
VerticalScalingPolicy
so that the IG simply does not provide instanceType and VSP can be provided as follows:We should also probably explore supporting something like HPA's
behavior
spec based on node capacity@backjo any thoughts on this, would you find this useful?
The text was updated successfully, but these errors were encountered: