Introduction

In Kubernetes, managing and optimizing resource usage is critical to ensure that the cluster operates efficiently. A common question among users is whether it's possible to enforce a hard memory limit on pods. In Kubernetes, resource limits are crucial for preventing a single pod from consuming too much memory and affecting the overall system stability. In this article, we will delve into how Kubernetes handles memory limits for pods, technical explanations, and examples of implementation.

Kubernetes Resource Management

Kubernetes manages resources through requests and limits for CPU and memory. These mechanisms ensure that pods can get the resources they need while not exceeding what is available in the cluster.

• Requests: This is the amount of CPU or memory that Kubernetes ensures a container gets.
• Limits: This defines the maximum amount of CPU or memory that the container can utilize.

Enforcing Memory Limits

In Kubernetes, enforcing a hard memory limit on pods means setting an upper bound on the memory usage, beyond which the pod will be subject to termination. This is achieved using the `resources` field in the container specification.

Here's how you can specify memory requests and limits in a pod definition:

• name: memory-demo-ctr
  • "--vm"
  • "1"
  • "--vm-bytes"
  • "128M"
  • "--vm-hang"
  • "1"
• The pod requests 64Mi of memory.
• The pod has a memory limit of 128Mi.
• Kubernetes creates a cgroup specific to the pod.
• The kernel is instructed via the cgroups mechanism not to permit the process within the cgroup to use more than the specified limit.
• When the process uses more than the allocated memory, it triggers an Out Of Memory (OOM) error.
• The kubelet then reacts to this message by terminating the pod.
• Burstable Pods: If a pod’s memory request is less than its memory limit, Kubernetes considers it to be of 'Burstable' QoS class. This implies that it can be terminated under memory pressure, despite not exceeding its own limit.
• Guaranteed Pods: When requests and limits are equal, the pod is of 'Guaranteed' QoS and is less likely to be killed in low-memory situations.
• OOMKilled Scenarios: A pod can still be killed even if it tries to allocate resources up to its limit but is limited by available host resources.
  • default: