Allocating Insufficient Resource than the Actual Usage

Allocating insufficient memory#

Let’s take a look at a slightly modified version of the go-demo-2 definition as go-demo-2-insuf-mem.yml. When compared with the previous definition, the difference is only in resources of the db container in the go-demo-2-db Deployment.

The memory limit is set to 20Mi and the request to 10Mi. Since we already know from Metrics Server’s data that MongoDB requires around 35Mi, memory resources are this time, much lower than the actual usage.

Applying the definition#

Let’s see what will happen when we apply the new configuration.

We applied the new configuration and retrieved the Pods. The output is as follows.

In your case, the status might not be OOMKilled. If so, wait for a while longer and retrieve the Pods again. The status should eventually change to CrashLoopBackOff.

As you can see, the status of the go-demo-2-db Pod is OOMKilled (Out Of Memory Killed). Kubernetes detected that the actual usage is way above the limit and it declared the Pod as a candidate for termination.

The container was terminated shortly afterward. Kubernetes will recreate the terminated container a while later only to discover that the memory usage is still above the limit. And so on, and so forth. The loop will continue.

ℹ️ A container can exceed its memory request if the node has enough available memory. On the other hand, a container is not allowed to use more memory than the limit. When that happens, it becomes a candidate for termination.

Looking into the deployment’s description#

Let’s describe the Deployment and see the status of the db container.

The output, limited to relevant parts, is as follows.

We can see that the last state of the db container is OOMKilled. When we explore the events, we can see that, so far, the container was restarted eight times with the reason BackOff.

Try it yourself#

For your ease, all the commands used in this lesson are given below.