Resource requests and limits are a reliability feature that also works as a security control. A limit caps what one container can consume, so a runaway process, a cryptominer or a denial of service attempt is contained to a bounded slice of the node. Set them on every container, and enforce that with policy.
How requests and limits differ
According to the Kubernetes docs, the request is used by the scheduler to place the pod and the kubelet reserves at least that amount for the container. The limit is enforced by the kubelet and container runtime, and ultimately by the Linux kernel through cgroups. A container may use more than its request if the node has spare capacity.
If you set a limit without a request, and nothing supplies a default, Kubernetes uses the limit as the request.
How each limit is enforced
CPU limits work by throttling. The container cannot use more CPU than its limit.
Memory limits are enforced reactively. A container can exceed its limit briefly, and it is terminated through an out of memory kill when the kernel detects memory pressure. So you may not see an instant kill at the boundary.
The security angle
With no limits, one compromised or misbehaving pod can consume enough CPU or memory to slow or evict its neighbors. The RBAC good practices page has a section on denial of service through object creation, and the multi-tenancy docs treat denial of service as a core concern for tenants that do not trust each other. Limits do not stop an attacker, but they reduce the blast radius of resource abuse.
Limits also give detection a signal: a pod that suddenly hits its CPU cap or is repeatedly OOM killed deserves a look.
Practical rules
- Set memory limits on every container. Base them on observed use plus headroom.
- Be thoughtful with CPU limits. Throttling can hurt latency, so some teams set requests and skip CPU limits for trusted services. Make that a documented decision, not an accident.
- Use namespace level defaults and quotas so teams that forget still get limits. Check the Kubernetes documentation for LimitRange and ResourceQuota in your version.
- Enforce with admission. A ValidatingAdmissionPolicy can reject pods with no limits. See ValidatingAdmissionPolicy versus webhooks.
- Alert on OOM kills and throttling.
Safeguard policies and gates can also require resource limits in manifests at the pull request, before they reach the cluster.
Where to start tomorrow
List pods with no memory limit. Group them by namespace and owner, and send each team its own list. For new namespaces, add a default and a quota in your namespace template. Pick one alert, such as repeated OOM kills, and route it to the owning team. That small set closes most of the gap.
Quick check
Does a memory limit kill the container the moment it is crossed?
Not necessarily. The docs say enforcement is reactive and the kill happens when the kernel detects memory pressure.
Are limits enough to stop a cryptominer?
No. They cap the damage. You still need to prevent the compromise and detect the behavior.
Sources
- Resource Management for Pods and Containers, Kubernetes documentation
- RBAC good practices
- Multi-tenancy
Last reviewed: 19 October 2026.
