<p>Take a look at the <a href="https://github.com/kubernetes-sigs/descheduler" rel="nofollow noreferrer">Descheduler</a>. This project runs as a Kubernetes Job that aims at killing pods when it thinks the cluster is unbalanced.</p>
<p>The <a href="https://github.com/kubernetes-sigs/descheduler#lownodeutilization" rel="nofollow noreferrer"><code>LowNodeUtilization</code></a> strategy seems to fit your case:</p>
<blockquote>
<p>This strategy finds nodes that are under utilized and evicts pods, if
possible, from other nodes in the hope that recreation of evicted pods
will be scheduled on these underutilized nodes.</p>
</blockquote>
<hr />
<p>Another option is to apply a little of chaos engineering manually, forcing a Rolling Update on your deployment, and hopefully, the scheduler will fix the balance problem when pods are recreated.</p>
<p>You can use the <code>kubectl rollout restart my-deployment</code>. It's way better than simply deleting the pods with <code>kubectl delete pod</code>, as the rollout will ensure availability during the &quot;rebalancing&quot; (although deleting the pods altogether increases your chances for a better rebalance).</p>

CC BY-SA 4.0
2020-10-23T14:30:10.203Z
2020-10-23T14:30:10.203Z
Eduardo Baitello
<p>You should look into affinity and anti-affinity as that allows you to control what pods go on which node. You can have it so that with anti-affinity there is only 1 pod of each deployment on a node. This is a bit overkill and wouldn't work for you exactly though IIRC you can have multiple pods on a node just with a limit.</p>
<p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/</a></p>

CC BY-SA 4.0
2020-08-21T02:19:27.737Z
2020-08-21T02:19:27.737Z
joshk132
<p>Current using AWS's auto-scale policy to start EKS worker nodes (min+desired 10, max 15) on a fixed time every day. There are 120 pods and 30 deployments.</p>
<p>Obviously, only one node will be up firstly. Then the second node. After that last node will be up.
For that reason, Kubernetes add all pods in the first nodes.
Is there any way so that pods will be evenly distributed in the scenario?</p>

<amazon-web-services><kubernetes><autoscaling><eks>
Spread pods over cluster
again
# Spread pods over cluster

(Asked by: username_0 on 2020-08-19)

Current using AWS's auto-scale policy to start EKS worker nodes (min+desired 10, max 15) on a fixed time every day. There are 120 pods and 30 deployments.

Obviously, only one node will be up firstly. Then the second node. After that last node will be up.
For that reason, Kubernetes add all pods in the first nodes.
Is there any way so that pods will be evenly distributed in the scenario?

**Tags:** amazon-web-services, kubernetes, autoscaling, eks


---

## 2 answers

### Answer by username_1 on 2020-10-23. Score: 1 | Accepted answer

Take a look at the [Descheduler](https://github.com/kubernetes-sigs/descheduler). This project runs as a Kubernetes Job that aims at killing pods when it thinks the cluster is unbalanced.

The [`LowNodeUtilization`](https://github.com/kubernetes-sigs/descheduler#lownodeutilization) strategy seems to fit your case:

> This strategy finds nodes that are under utilized and evicts pods, if
> possible, from other nodes in the hope that recreation of evicted pods
> will be scheduled on these underutilized nodes.

---

Another option is to apply a little of chaos engineering manually, forcing a Rolling Update on your deployment, and hopefully, the scheduler will fix the balance problem when pods are recreated.

You can use the `kubectl rollout restart my-deployment`. It's way better than simply deleting the pods with `kubectl delete pod`, as the rollout will ensure availability during the "rebalancing" (although deleting the pods altogether increases your chances for a better rebalance).


---

### Answer by username_2 on 2020-08-21. Score: 2

You should look into affinity and anti-affinity as that allows you to control what pods go on which node. You can have it so that with anti-affinity there is only 1 pod of each deployment on a node. This is a bit overkill and wouldn't work for you exactly though IIRC you can have multiple pods on a node just with a limit.

<https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/>


---

