Auto Scaling Group for master node
asymmetric opened this issue · comments
Benefits
- Faster operator (it wouldn't have to wait for instances to be "ready")
- Only one way of starting instances
- Getting rid of old code (
runMachine/runMachines)
Cons
- Is it worth investing the time, since we plan on moving masters to pods on host cluster anyway?
Questions
- How to ensure master won't get killed by AWS, thereby losing all etcd state?
/cc @rossf7
@asymmetric I'm closing this. I don't think its worth spending time since the master setup is going to change. It would be better to spend the time moving the control plane to the host cluster.
Reopened because situation changed and we will not move masters to host clusters for now. So we might want to have this solved here at some point.
I think using an ASG for the masters makes sense.
I'd prefer it if we moved etcd to the host cluster first. As the ASG can then replace failed masters without the cluster losing state.
Closing as its blocked until etcd is off the master node