<p>Why should K8S Deployments/Pods set <strong>Memory</strong> Limit (which seems to be a recipe to find yourself in a crash loop) rather than each Deployment simply being responsible for setting its own Memory <strong>Request</strong> high enough that it won't be killed?</p>

vmayer
<p>By setting requests but not limits you get the Quality of Service (QOS) <a href="https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-burstable" rel="nofollow noreferrer">Burstable</a>. Without limits set your pod is able to consume all &quot;available&quot; cpu and memory on a node. &quot;Available&quot; resources are those that are not allocated to other pods via requests. This does NOT include resource limits.
What you should consider is whether the process in the container will try to use more memory than your request.
If for instance you have a java application then you will want to set the max heap size (<code>Xmx</code>) to less than the limit. But not everything that people run in containers has this type of memory control.</p>
<p>If you are sure you container only needs x amount of memory then what you want is the <a href="https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed" rel="nofollow noreferrer">Guaranteed QOS</a>. i.e set limit and request to the same value. It sounds like your container is trying to use more than your memory request. If it is, you should consider something similar to the java max heap size configuration.</p>
<p>Setting a memory limit is a safeguard (if you need a safe guard i.e you don't want the pod evicted unpredictably). A good use case for burstable QOS is a pod that needs a bit of extra memory &quot;sometimes&quot; e.g e-commerce site for coffee that always gets busy between 7am-9am but is quite for the rest of day.</p>
