<p>Suppose I have a 3 node EKS cluster made up of 3 spot instances (we'll call them Node A, B, and C), and each node has critical pods scheduled. The EKS cluster has the EKS Node Termination Handler running.  Metadata gets posted saying that in 2 minutes Node A is going to be reclaimed by Amazon.</p>
<p>The Node Termination handler cordons and drains the node being taken (Node A), and a new node spins up.  The pods from Node A are then scheduled on the Node A Replacement.  If this completes in two minutes time, perfect.</p>
<p>Is there a benefit to having spare capacity around (Node D).  If Node A is taken back by Amazon, will my pods be rescheduled on Node D since it is already available?</p>
<p>In this architecture, it seems like a great idea to have a spare node or two around for pod rescheduling so I don't have a risk of the 2 minute window.  Do I need to do anything special to make sure the pods are rescheduled in the most efficient way?</p>

Christian Aranda
<blockquote>
<p>Is there a benefit to having spare capacity around (Node D). If Node A is taken back by Amazon, will my pods be rescheduled on Node D since it is already available?</p>
</blockquote>
<p>Yes definitely, there are chances POD will get scheduled on that node if not any specific argument attached to deployment like <strong>Node selector</strong>, <strong>taint</strong>, <strong>affinity</strong> etc.</p>
<blockquote>
<p>Do I need to do anything special to make sure the pods are rescheduled
in the most efficient way?</p>
</blockquote>
<p>That sounds a good idea but what if all at the same time <strong>3</strong> PODs get termination signal, in 2 Min all POD can be rescheduled to new Nodes?</p>
<p>New <strong>3</strong> nodes will be available or <strong>Single D</strong> node will be available?</p>
<p>You might need to take care about the Size of all PODs being scheduled on the number of Nodes, Readiness-liveness with proper fast configuration so POD comes up asap and handle the traffic.</p>
<p>If your <strong>Single D</strong> node is running, and all <strong>3</strong> Spot instances get terminated that can create issue, How about the PODs of <strong>Nginx ingress</strong> or <strong>service mesh</strong> you will be running?</p>
<p>If Nginx PODs are getting scheduled, those may take a few sec time sometimes if they are <strong>Rollingupdate</strong> then it's fine.</p>
