Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsTo fix a Kubernetes OOMKilled error, first determine whether the container hit its memory limit or the node ran short of memory. Check the container’s previous termination record, its effective request and limit, Pod events, usage history, and node conditions. Then fix a demonstrated memory problem or make a measured resource adjustment, roll it out through the owning controller, and verify that restarts stop without creating node pressure.
1. Confirm which container was killed and when
Start with the affected Pod’s last termination record and restart count:
kubectl get pod POD -n NAMESPACE -o yamlUnder the relevant container, inspect lastState.terminated, especially reason, exitCode, and the termination timestamps. Kubernetes’ memory-resource exercise demonstrates reason: OOMKilled and exit code 137 after a container exceeds its memory limit. Treat these fields as evidence to investigate, not as a complete diagnosis on their own.
Then inspect the Pod’s configuration and recent events:
#1 Best Overall
kubectl describe pod POD -n NAMESPACECheck which container restarted, its configured resources, and whether events mention memory pressure, eviction, or scheduling. If the Pod is managed by a Deployment, StatefulSet, Job, or another controller, make corrective changes to that controller’s template rather than editing a transient Pod.
2. Check the effective request and limit
Inspect the live Pod, not only the manifest you expect to be running. Compare the affected container’s resources.requests.memory and resources.limits.memory. A namespace LimitRange may have supplied defaults or enforced minimum and maximum values, so check the namespace configuration as well.
The two settings serve different purposes:
- Memory request: primarily an input to scheduling. Kubernetes uses requests when deciding whether a Pod fits on a node; memory use above a request does not by itself prevent another Pod from being scheduled.
- Memory limit: a runtime ceiling. On Linux, container runtimes typically configure kernel cgroups to enforce limits, and an overrun can trigger the kernel’s OOM behavior. Enforcement is reactive, so a kill can occur as the kernel detects pressure.
A container can exceed its request while remaining below its limit. Conversely, a large request can cause a Pod to stay pending with an insufficient-memory scheduling event; that is not the same as a running container being OOMKilled. If no container limit is configured and no namespace default applies, the container has no container-level upper bound and can consume node memory.
Rank #2
3. Compare memory use with the limit
If the cluster has metrics support, take a current sample with:
kubectl top pod POD -n NAMESPACEThis can show whether current usage is near the configured limit, but it is only a snapshot. A brief spike may have caused the kill and disappeared by the time you inspect the Pod. Use the monitoring history available in your cluster to compare peaks with the limit before changing values.
Look for a repeatable pattern: memory rising steadily over time, spikes tied to traffic or batch work, or a process that approaches its limit only under particular concurrency. The Kubernetes documentation’s memory example illustrates that usage can exceed a request while staying below a limit; requests should not be mistaken for runtime caps.
4. Investigate the workload before increasing memory
A higher limit may be appropriate for an expected peak, but it will not correct a leak or an unexpectedly large allocation. Review the application and its runtime for evidence of:
- Memory that grows without returning or stabilizing, which may indicate a leak.
- Large batches, caches, buffers, or runtime heaps that exceed intended bounds.
- Concurrency or traffic spikes that multiply per-request memory use.
- Configuration changes that increase working-set size.
These are investigation paths, not causes that can be inferred from the OOMKilled label alone. Use application and runtime monitoring to connect a suspected cause to the time of the termination.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check memory-backed emptyDir volumes
An emptyDir configured with medium: Memory uses memory rather than ordinary node storage. Inspect its sizeLimit and the Pod’s memory limit. Kubernetes notes that without a volume size limit, a memory-backed volume may consume up to the Pod’s memory limit; if there is no applicable limit, node memory can be at risk. Set a deliberate volume bound where appropriate, taking the application’s actual temporary-storage needs into account. See the resource management documentation.
5. Distinguish a container-limit kill from node memory pressure
A container crossing its own limit and a node running short of memory are related but distinct conditions. Review Pod events alongside node conditions and node-level OOM records. A container-limit kill points toward the container’s configured ceiling and workload use; node pressure requires attention to total demand and the node’s available capacity.
Kubernetes warns that kubelet polling may not observe MemoryPressure quickly enough when memory use rises rapidly and the kernel OOM killer acts first. On Linux, kubelet’s memory.available calculation is derived from cgroup information, so free -m inside a container does not show the node’s eviction calculation. Consult the node-pressure eviction documentation for details and check the behavior of your Kubernetes version, Linux setup, and runtime.
6. Choose a fix that matches the evidence
| Evidence | Action to consider | Trade-off to check |
|---|---|---|
| Usage rises unexpectedly or a leak or oversized allocation is demonstrated. | Correct the application, runtime, batch, cache, buffer, or concurrency behavior first. | Raising the limit can postpone another kill while allowing the underlying problem to consume more memory. |
| Usage peaks are expected, repeatable, and supported by monitoring history. | Consider increasing the container limit to accommodate the observed workload. | A higher limit can shift pressure to the node; verify node capacity and other workloads. |
| Scheduling fails with insufficient memory after a request change. | Reassess the request against observed demand and available node allocatable capacity. | Requests affect placement; a request that no node can satisfy can leave Pods pending. |
A memory-backed emptyDir is a substantial or unbounded part of usage. |
Set or revise its sizeLimit and review the Pod’s memory budget. |
A volume bound must still allow the application’s legitimate temporary-memory needs. |
| Node evidence shows memory pressure beyond one container’s configured limit. | Address aggregate workload demand and node capacity, not just the affected container’s limit. | Adding capacity or changing placement is justified only when node-level evidence supports it. |
If you change a limit, consider whether the request should also change, based on scheduling needs and node capacity. Do not set either value by guesswork: the Kubernetes documentation does not prescribe one universal memory size for workloads. Make the change through the owning controller, then monitor restart counts, usage trends, scheduling outcomes, and node pressure.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute7. Account for namespace policies and version differences
A LimitRange can inject default requests or limits when a Pod is created, and its minimum or maximum constraints can cause Pod creation or updates to be rejected. Changing a LimitRange does not retroactively change existing Pods, so inspect the live Pod after applying a policy change. The LimitRange documentation describes these behaviors.
Check your Kubernetes version, Linux and container-runtime configuration, workload controller, and provider-specific monitoring before applying operational guidance. In particular, cgroups v2 and MemoryQoS details are version-sensitive: Kubernetes’ 2023 MemoryQoS article describes an alpha feature in the Kubernetes 1.27 context, not a universal setting to assume across clusters.
8. Verify the fix after rollout
After the controller has created replacement Pods, check that the affected containers remain ready and their restart counts stop increasing. Compare their memory trend with the intended limits, review new Pod events, and check node conditions and pressure. A change is successful only if it resolves the termination without simply moving the problem to scheduling or the node.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
