<p>In have a situation where the node has <code>4GB memory</code> and actual memory usage looks as below:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Pod</th>
<th>Memory Requested</th>
<th>Memory Limit</th>
<th>Memory Used</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>2.0 GiB</td>
<td>3.0 GiB</td>
<td>1.0 GiB</td>
</tr>
<tr>
<td>2</td>
<td>2.0 GiB</td>
<td>3.0 GiB</td>
<td>1.0 GiB</td>
</tr>
<tr>
<td>Free</td>
<td>0.0 GiB</td>
<td>0.0 GiB</td>
<td>2.0 GB</td>
</tr>
</tbody>
</table>
</div>
<p>Since there is free memory, nothing gets evicted.</p>
<p>But now let's say both pods 1 and 2 start doing real work, and the situation changes to</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Pod</th>
<th>Memory Requested</th>
<th>Memory Limit</th>
<th>Memory Used</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>2.0 GiB</td>
<td>3.0 GiB</td>
<td>3.0 GiB</td>
</tr>
<tr>
<td>2</td>
<td>2.0 GiB</td>
<td>3.0 GiB</td>
<td>2.0 GiB</td>
</tr>
</tbody>
</table>
</div>
<p>and the Kubernetes eviction algorithm gets triggered.</p>
<p>In such a situation which pod will be evicted? Will it be <code>pod1</code> or <code>pod2?</code>.</p>
<p>I have already checked <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction" rel="nofollow noreferrer">pod selection rules</a>, but still not able to get an understanding of how eviction will work in this case.</p>

<p>In your example, pod 1 will get evicted.  The Pod that is not using more memory than it requested will not get evicted.</p>
<p>This is mentioned in the Kubernetes documentation you link to:</p>
<blockquote>
<p>The kubelet uses the following parameters to determine the pod eviction order:</p>
<ol>
<li>Whether the pod's resource usage exceeds requests</li>
<li>Pod Priority</li>
<li>The pod's resource usage relative to requests</li>
</ol>
</blockquote>
<p>In your example, pod 2's resource usage does not exceed requests (memory requested=2 GiB, actual use=2 GiB) so it is removed from the algorithm.  That leaves pod 1 as the only pod remaining, and it gets evicted.</p>
<p>Say pod 2 is also above its request.  Then for both pods, subtract actual utilization from the request, and the pod that's the most over its limit gets evicted.</p>
<p>Let's look at a little more complex example on a hypothetical 8 GiB node:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Pod</th>
<th>Requested</th>
<th>Actual</th>
<th>Excess use</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>4.0 GiB</td>
<td>4.0 GiB</td>
<td>0.0 GiB</td>
</tr>
<tr>
<td>2</td>
<td>1.0 GiB</td>
<td>2.0 GiB</td>
<td><strong>1.0 GiB</strong></td>
</tr>
<tr>
<td>3</td>
<td>1.0 GiB</td>
<td>1.3 GiB</td>
<td>0.3 GiB</td>
</tr>
<tr>
<td>4</td>
<td>0.0 GiB</td>
<td>0.8 GiB</td>
<td>0.8 GiB</td>
</tr>
</tbody>
</table>
</div>
<p>Pod 1 is using the most memory, but it is within its requests, so it is safe.  Subtracting actual use from requests, pod 2 is using the most excess memory and it is the one that will get evicted.  Pod 4 hasn't declared resource requests at all, and while it's safe in this scenario, it's at risk in general; absent pod 2, it's the pod using the most memory above its requests, even though it's the second-least absolute memory.</p>
