Consider a Deployment that runs 1 Pod containing a NodeJS container with no specified resource limits. My Kubernetes Cluster consists of 3 Nodes and is running different applications, 2 of the Nodes that are running other applications than NodeJS are experiencing a steady high load (i.e. CPU utilization > 80%), deeming scheduling new Pods into those Nodes ineffective.
| Pod:A | | Pod:A | | Pod:NodeJS |
| Pod:B | | Pod:B | | |
|--------| |--------| |---------------|
|CPU 85% | |CPU 85% | | CPU 60% |
|Mem:80% | |Mem:85% | | Mem:70% |
Node 1 Node 2 Node 3
In the case where NodeJS application experiences high loads, would there be any benefits if I scale up the Deployment that an extra Pod would also run on Node 3, considering no resource limits defined?
| Pod:NodeJS |
| Pod:NodeJS |
|---------------|
| CPU 60% |
| Mem:70% |
Node 3
As you know, Pods are an ephemeral entity in kubernetes. They get killed without prior notice. In your example you have a single pod for your nodeJS application, thus if you pod gets rescheduled for whatever reason you'll end up with a downtime in your service. For this reason it makes sense IMHO to scale up your pod in order to have multiple instances of it running simultaneously. Obviously, if all instances are run on the same node, a failure in that node will still cause you a downtime, but this should happen much less frequently than a pod reschedule.