kubernetes-resource-debugginglisted

# Kubernetes Resource Debugging Decide what a container actually needs, using measurements, before changing a request or a limit. ## Purpose **Use this when:** - A container is `OOMKilled` (exit 137). - A pod is `Pending` with `Insufficient cpu` or `Insufficient memory`. - A workload is slow and CPU throttling is suspected. - Nodes report `MemoryPressure` or `DiskPressure`, or pods are being `Evicted`. - Someone is about to change `requests` or `limits` and has no measurement to justify it. **Do not use this when:** - The container is crashing with a non-137 exit code — that is an application failure; use `kubernetes-troubleshooting`. - The slowness is in a downstream dependency — use `production-debugging`. **What this skill assumes:** metrics-server for `kubectl top`, and ideally Prometheus with kube-state-metrics and cAdvisor for historical data. Instantaneous `top` output is not enough to size a limit; peak usage is what kills containers. ## Operating Procedure 1. **Establish what the workload is configured to get.** Read requests and limits from the spec, not from memory or from a wiki. 2. **Measure what it actually uses.** Current usage via `kubectl top`, and the peak over a meaningful window via Prometheus. One number at one moment is not a measurement. 3. **Separate the two independent failures.** Memory limits kill. CPU limits throttle. They have different symptoms, different metrics, and different fixes — never treat them together. 4. **Check nod