Agent Kubernetes Resource Requests, Limits, and OOMKills

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Kubernetes requests, limits, QoS, and OOMKilled events are core evidence when agents debug pods that restart, fail scheduling, or degrade under memory pressure.

## Core Explanation

Requests drive scheduling and capacity placement; limits define enforcement boundaries. A pod can be unschedulable when requests exceed available node capacity, or it can start successfully and later restart because runtime memory exceeds the container limit.

Agents should inspect pod specs, recent events, container last state, restart count, node allocatable resources, QoS class, cgroup memory metrics, and deployment history before deciding whether to increase limits, reduce concurrency, or fix a leak.

## Source-Mapped Facts

- Kubernetes documentation says containers can specify resource requests and limits for CPU, memory, ephemeral storage, and huge pages. ([source](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/))
- Kubernetes documentation says the scheduler checks that the sum of scheduled container resource requests is less than node capacity. ([source](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/))
- Kubernetes documentation on memory assignment shows that a container can be terminated when it tries to use more memory than its configured limit. ([source](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/))

## Further Reading

- [Kubernetes Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)
- [Kubernetes Assign Memory Resources](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/)
- [Kubernetes Node-Pressure Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/)