---
# System prepended metadata

title: Why Memory Limit is Important for K8s Applications

---

# Why Memory Limit is Important for K8s Applications

![](https://lh3.googleusercontent.com/AOq1YOZWgLrje7mU_OD7HJmqMbDWNN2GeThYAuZBclVWMt375aB7V0B3sC4p_FV4GCwINNaMVeGNMw_CArST0abtM9tynMFdpcPRopI_rtfcQcmB3WOMnyvnhScyXVIj6Q)

[Photo](https://unsplash.com/photos/95YRwf6CNw8) by [Clément Hélardot](https://unsplash.com/@clemhlrdt?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash

Kubernetes limits are the mechanisms one employs to control resources such as CPU and memory. The container's limits define the maximum amount of resources that it can consume. Limits ensure that a container never exceeds a certain value---the container is restricted as soon as it hits the limit. Setting limits is useful for preventing over-commitment of resources and protecting other deployments from resource depletion.

In this article, we will discuss why memory limits are important for K8 applications and how to set memory limits in your K8 application.

## Why Is It Important to Set Memory Limits?

Requests and limits are applied per container. While the majority of pods only have one single container, it is not rare to see pods with multiple containers. Each container in the Pod has its own request and limit. But because pods are always scheduled as a single group, you must add the limits and requests for each container together to get the Pod's total value.

When an application consumes more memory than is allowed, Kubernetes terminates the process with an OOMKilling (Out of Memory Killing) message. However, as soon as that happens, the process is immediately terminated. OOMKilled, which basically means it has [exited with code 137](https://komodor.com/learn/how-to-fix-oomkilled-exit-code-137/), is a very common problem for developers, and we must set a perfect memory limit to solve it.

How to Set Memory Limit
-----------------------

You must have a Kubernetes cluster and the kubectl command-line tool configured to communicate with it. This tutorial should be done on a cluster with at least two nodes that aren't acting as control plane hosts. If you don't have a cluster, you may build one using minikube or use Kubernetes playgrounds.

### Create a Namespace

Create a namespace to keep the resources created in this exercise separate from the rest of your cluster.

### Set a memory request and a [memory limit](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/#specify-a-memory-request-and-a-memory-limit)

Include the resources:requests field in the container's resource manifest to specify a memory request. Include resources:limits to set a memory limit. It is important to note that the limit can never be lower than the request. If you try this, Kubernetes will throw an error and prevent you from running the container.

The container has a 100 MiB memory request and a memory limit of 200 MiB. Here's the pod's configuration file:

![](https://lh6.googleusercontent.com/6ugc-Iv-4ILFrRC493c8DFn-f7d7z_gs6hCzZrFhg9VU3wIOPbkzS12k19118QlWYy9tMYLDjq5Jk42vfbMFkNtVFFRBnqB8ZpL-2hF7SAiC25DyLSd63OG7g6gwnbK35w)

### Exceed the Memory Limit of a Container (Exit Code 137)

If the node has enough memory, a container can exceed its memory request. A container, on the other hand, is not allowed to use more memory than it has. If a container allocates more memory than it is allowed, the container will be terminated. Kubelet restarts a terminated container if it can be resumed, much like any other form of runtime failure.

Let's say the container attempts to allocate 200 MiB of memory but this is far more than the 100 MiB limit as per the args section of the configuration file. The container could be running or dead at this point.

The output shows that the container was killed because it was out of memory (OOM):

![](https://lh3.googleusercontent.com/0O_TjbgUwoNsYDxVaIsDark1j3GnAbWr3FQWzgdR4X2JQX5wYIJ2cR17HlZrNGZXD5wMO7GgkIe-40gIah00lwmCJdmhicH4JLDOH_ae8WEMp_K05BRRO9H-YDDNMyYx4g)

### Namespace Settings

You can set quotas at the container and namespace levels to control what limits a container can have.

[limits.cpu](https://wbhegedus.me/understanding-kubernetes-cpu-limits/) is the namespace's maximum aggregate CPU limit for all containers. It's the same with requests.cpu, but only up to a certain point.

[limits.memory](https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-memory-6b41e9a955f9) is the namespace's maximum aggregate memory limit for all containers. It's the same with requests, but only until the point of exhaustion.

In your namespace, you can also create a [LimitRange](https://docs.openshift.com/container-platform/3.6/admin_guide/limits.html). A LimitRange, unlike a quota, applies to a single container rather than the entire namespace. This can help prevent people from making containers that are too small or too big for the namespace.

When using a production and development namespace (rather than a namespace for each team or service), a common pattern is to give the production namespace no quotas and the development namespace strict quotas. This allows production to use all the resources it requires in the event of a traffic spike.

## What Happens If a Memory Limit Isn't Specified?

If a memory limit is not set, one of the following situations may arise.

The container has no limit on how much memory it can use so it consumes all the available memory on the Node where it is running, triggering the OOM Killer. Furthermore, a container with no resource limits will have a higher chance of being killed in the event of an OOM kill.

Alternatively, the container may be running in a namespace with a default memory limit, and the default limit gets assigned to the container automatically. A LimitRange can be used by cluster administrators to set a default value for the memory limit.

## The Purpose of Memory Limits

You can make efficient use of the memory resources available on your cluster's nodes by configuring memory limits for the containers that run in your cluster. You give a pod a good chance of being scheduled by keeping its memory request low.

You accomplish two things by setting a memory limit that is higher than the memory request. One, the pod can have bursts of activity in which it makes use of any available memory. Or two, during a burst, the amount of memory a pod can use is limited to a reasonable amount.

Conclusion
----------

I hope this article has helped you understand why a memory limit is important for your K8 application. With this article, you now know how to set a memory limit in your application or project in an efficient manner. Please like the article if you found it helpful and follow for more articles.