Utilities

Kubernetes Pod Right-Sizer

Calculate CPU and memory requests and limits for Kubernetes pods from average and p95 utilization. Generates a complete resources YAML block ready to paste into your Deployment manifest.

Different request/limit. Most common.

CPU usage (millicores)

AverageTypical CPU during normal operation
m
p9595th percentile under load
m

Memory usage (MiB)

AverageTypical RSS during normal operation
Mi
p95Peak RSS under load
Mi
0% (tight)30% (recommended)100% (very generous)

CPU

Request165m
Limit585m

Memory

Request462Mi
Limit546Mi

Generated YAML

spec:
  containers:
    - name: app
      image: your/image:tag
      resources:
        requests:
          cpu: "165m"
          memory: "462Mi"
        limits:
          cpu: "585m"
          memory: "546Mi"

Automate your incident response

Reduce MTTR by 90% with AI-powered root cause analysis. Free to start.

Try Uptimes.ai Free

The cost of getting requests and limits wrong

Under-provisioned pods get OOMKilled in production at the worst possible moment. Over-provisioned pods waste money and reduce scheduling flexibility — fewer pods fit per node, you need more nodes, your bill doubles. The right-sizing calculator above splits the difference: CPU request near average (CPU is compressible, so you can be aggressive), memory request near p95 (memory is incompressible, so you cannot afford to be wrong), and limits with a safety margin on top.

When to scale up vs scale out

A common mistake is sizing pods up rather than scaling out replicas. As a rule of thumb:

  • CPU limit ≥ 4 cores — usually a signal to add more replicas. Larger pods reduce scheduler flexibility and increase blast radius when one fails.
  • Memory limit ≥ 8Gi — confirm the workload actually needs it. JVM apps and ML inference are common legitimate cases; web servers usually are not.
  • Spiky traffic — prefer HPA scaling out small pods over big pods sized for the peak.

Catching right-sizing mistakes in production

The most common right-sizing failures show up as OOMKill events, CPU throttling, or pending pods stuck in scheduling. All three are telemetry-rich — Kubernetes events, kubelet metrics, and container runtime stats expose them. Uptimes.ai watches for these signals continuously, correlates them with recent deploys via the GitLab integration, and surfaces "your last deploy made pod X OOMKill twice since 09:00" instead of waiting for an alert from a downstream symptom.

Frequently Asked Questions

What is the difference between requests and limits?+
Requests are what Kubernetes guarantees the pod — the scheduler reserves that much capacity on the node, and the pod can always use up to that amount. Limits are the maximum the pod can ever consume; exceeding the CPU limit causes throttling, exceeding the memory limit causes OOMKill. Setting requests too low causes scheduling on overcrowded nodes; setting limits too low causes preventable failures.
Why is the memory request set close to p95?+
Memory is incompressible. If your pod is using 400 MiB and the OS needs to take memory away from it, the only way is to OOMKill the pod — there is no equivalent of CPU throttling. Setting memory request below p95 means under load the kernel may pick your pod for eviction even though it is using memory it actually needs. CPU requests can be more aggressive (set near average) because CPU is compressible — exceeding it just throttles.
What is QoS class and which should I pick?+
Kubernetes assigns one of three QoS classes to every pod based on requests/limits. Guaranteed (request == limit) is most predictable and never gets evicted before lower classes. Burstable (request < limit) is the default for most workloads — predictable scheduling but can use more under load. BestEffort (no requests/limits) is evicted first under node pressure. For production app workloads, prefer Burstable; for latency-sensitive workloads (databases, real-time services), prefer Guaranteed.
Should I just enable the Vertical Pod Autoscaler instead?+
VPA is great for "set and forget" right-sizing on workloads with stable utilization patterns. Use this calculator for the initial sizing or when you do not have VPA installed. Note that VPA in update mode restarts pods to apply new sizes, which is disruptive — many teams run VPA in recommendation-only mode and use those recommendations as inputs to manual reviews.
How do I get accurate average and p95 utilization?+
Query Prometheus over the last 7-14 days: avg_over_time(container_cpu_usage_seconds_total[1h]) for CPU averages, quantile_over_time(0.95, ...) for p95. Datadog's container_cpu.usage and container_memory.rss with avg / quantile reductions work the same way. The longer the window, the more representative the numbers — but include peak traffic days.

Related Tools

Datadog Cost Estimator

Estimate your monthly Datadog bill for K8s monitoring.

Prometheus Cardinality Estimator

Estimate Prometheus series count and memory.

SLA & Uptime Calculator

Calculate allowed downtime for any SLA percentage.