This guide was written by Arthur Azrieli , CTO at MeteorOps, and first published on the MeteorOps blog .

Set a CPU request and a memory request on every container, sized from real usage: the 95th percentile of CPU and the peak memory working set over one to two weeks, plus headroom. Set the memory limit equal to the memory request. For latency-sensitive services, leave the CPU limit off (or set it well above the request) unless you have a specific reason to cap CPU. That combination keeps the scheduler honest, avoids Completely Fair Scheduler (CFS) throttling, and makes out-of-memory (OOM) kills predictable instead of random.

The rest of this guide explains why each of those rules exists, shows how to measure the numbers with PromQL and kubectl, covers the exceptions (multi-tenant clusters, batch jobs, quotas, Guaranteed pods), and ends with runtime settings for the JVM, Go and Node.js, a troubleshooting table, and a checklist.…