Containers without resource limits can consume unbounded CPU and memory — a runaway process, a traffic spike, or a memory leak starves other pods on the same node, triggering cascading OOM kills and node instability (CIS Kubernetes 5.7.4, ISO 25010 performance efficiency). Without resource requests, the Kubernetes scheduler has no data for placement decisions, leading to uneven node utilization and unexpected evictions under load. A single container with no memory limit can consume all memory on a node and bring down unrelated production workloads.
Low because unbounded resource consumption primarily causes availability impact through node exhaustion rather than enabling direct data access or privilege escalation.
Define both requests and limits for CPU and memory on every container in k8s/deployment.yaml. Size requests based on typical load and limits based on the worst-case load the application can handle before it's better to restart than to degrade:
containers:
- name: api
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
For initial sizing, deploy without limits in a staging environment and observe actual usage with kubectl top pods. Set limits at 2x the 95th-percentile observed usage. Use LimitRange objects to enforce defaults at the namespace level so new containers cannot be deployed without resource constraints.
ID: infrastructure-hardening.monitoring-incident-response.resource-limits
Severity: low
What to look for: Count every container across all Kubernetes Deployments, StatefulSets, and DaemonSets. For each container, check whether both resources.requests and resources.limits are defined for CPU and memory. Verify limits are reasonable: CPU limits under 4000m and memory limits under 4Gi for typical stateless services.
Pass criteria: Every container in every Deployment and StatefulSet defines both resources.requests and resources.limits for CPU and memory. Limits are set to reasonable values (e.g., CPU under 4000m, memory under 4Gi for stateless services). Report the count: "X of Y containers have both request and limit defined."
Fail criteria: Any container lacks resource requests or limits, or limits are set to unreasonably high values (e.g., memory over 16Gi for a stateless web service).
Skip (N/A) when: The project does not use Kubernetes.
Detail on fail: Quote the container and missing fields. Example: "Deployment 'api' container 'main' defines resource requests but no limits. Container could consume unlimited node resources." or "Memory limit is 16Gi for a stateless web service — unusually high"
Remediation: Define resource requests and limits:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
Set appropriate values based on your application's typical behavior. Monitor and adjust as needed.