Introduction

A Kubernetes pod does not have one universal RAM ceiling. Its effective memory limit depends on container limits, node capacity, and whether you defined limits at all. The short version is: a container can usually grow until it hits its own memory limit, and without a limit it can keep growing until the node is under pressure and something gets killed or evicted.

Start with container limits, not pod mythology

In Kubernetes, memory is enforced at the container level. A pod with one container behaves simply: the container can grow up to its configured limits.memory. If it tries to go beyond that, the kernel can OOM-kill it.

With multiple containers in one pod, each container has its own memory limit. The pod's total memory footprint is roughly the sum of all container usage plus some overhead.

Here is a typical deployment snippet:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: api
10  template:
11    metadata:
12      labels:
13        app: api
14    spec:
15      containers:
16        - name: api
17          image: ghcr.io/example/api:1.0.0
18          resources:
19            requests:
20              memory: "256Mi"
21            limits:
22              memory: "512Mi"

In this case, the container can usually grow to about 512Mi. Beyond that, it is in OOM territory.

What requests and limits really mean

requests.memory affects scheduling. It tells Kubernetes how much memory to reserve when placing the pod on a node.

limits.memory affects enforcement. It is the hard ceiling the container should not cross.

This distinction matters because a pod may request 256Mi but be allowed to grow to 1Gi if the limit is 1Gi. The scheduler only cares about the request. The runtime and kernel care about the limit.

Unlike CPU, memory is not throttled gracefully. If a process allocates too much memory, the outcome is usually an OOM kill rather than slower execution.

What if there is no memory limit

If you omit limits.memory, the container is not capped by a Kubernetes memory limit. That does not mean infinite growth. It means the container can consume memory until:

• the node runs low on memory
• the kernel OOM killer chooses a process to kill
• the kubelet evicts pods under memory pressure
• a namespace LimitRange or admission policy injects defaults you did not realize were present

So the practical answer becomes "up to what the node can spare before the cluster pushes back," which is not a stable number you should design around.

Node size and QoS class also matter

A pod cannot use memory that the node does not have. Even if a container limit is 8Gi, a pod scheduled on a small node may hit pressure much earlier because the node also needs memory for:

• the operating system
• kubelet and container runtime
• other pods
• page cache and kernel overhead

Kubernetes also assigns QoS classes based on requests and limits. Pods with equal requests and limits for every container become Guaranteed, which gives them better survival chances during eviction pressure than Burstable or BestEffort pods.

How to observe real memory usage

To see what a pod is actually using, start with:

kubectl top pod my-pod
kubectl describe pod my-pod

kubectl top shows current usage if Metrics Server is installed. kubectl describe pod helps you confirm the configured requests and limits and whether OOM kills have occurred.

For long-term capacity planning, use Prometheus and Grafana rather than spot checks. Memory problems are usually about peak behavior, not average behavior.

Common Pitfalls

• Thinking requests.memory is the maximum memory a pod can use. It is only the scheduler reservation.
• Assuming memory behaves like CPU and will just be throttled. Memory overuse usually ends in OOM kills or eviction.
• Forgetting that multi-container pods can consume the sum of several container limits.
• Omitting memory limits and then being surprised when node pressure causes evictions.
• Ignoring namespace LimitRange and ResourceQuota settings that may change the effective defaults.

Summary

• A container can generally grow up to its limits.memory value.
• Without a limit, it can grow until node pressure or OOM behavior stops it.
• 'requests.memory controls scheduling, not the hard maximum.'
• Multi-container pods can consume the combined memory of their containers.
• Measure real usage and set limits intentionally instead of relying on node headroom.