Kubernetes Resource Management is not only limiting resources!

In this paper, it is emphasized that restricting the resource usage of pods or containers is not a preference but a necessity because when restrict resources it also help to prevent memory leaks!

In Kubernetes resource management, “request” refers to the amount of resources a container or pod initially claims, while “limit” sets the maximum resources it can consume. These parameters help optimize resource allocation, ensuring efficient utilization within a cluster. For detailed information, please refer to the link provided below in the paper.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Let’s get to the main point! I have .net core service that running on Openshift. When I sent requests to a .NET core service without resource definition, I observed a continuous increase in memory. My initial suspicion was a memory leak or improper garbage collection. Taking action, I defined resources to safeguard the cluster from this service with escalating memory. My expectation was for the pod to restart when memory reached the defined limit. Surprisingly, with resource definition, the service began releasing memory as expected after handling requests.

How did this happen? As known, garbage collection is a costly process. In this case, without resource definition, .NET assumes it has resources equivalent to the node it runs on, choosing to use all available resources without incurring garbage collection costs. In essence, .NET states: “If I have resources to use, I’ll use them all, and I won’t bother with garbage collection.”

In conclusion, experience with a .NET service serves as a compelling case study, revealing the significance of resource definition in managing memory effectively. The unexpected outcome, where the service started releasing memory upon resource definition, reinforces the importance of proactive resource management.