Right-size Kubernetes requests and limits

Requests decide where pods are scheduled and how much of a node they reserve; limits decide when a container is throttled or OOM-killed. Set them too high and you pay for capacity nobody uses; too low and pods are evicted or killed under load. KubeEyes’ Health → Right-sizing compares each container’s settings with what it really used.

What it measures

• Every Deployment, StatefulSet and DaemonSet container in the namespaces you select, over the last 24 hours or 7 days, from Prometheus (cAdvisor’s container metrics).
• CPU: the 95th percentile and the peak of the 5-minute rate. Memory: the peak working set.
• All pods the workload has had in that time, including replaced ones.

How suggestions are made

• Suggested CPU request: the 95th percentile plus 20% headroom, in 10m steps (at least 10m).
• Suggested memory request: the peak plus 20%, in 16 Mi steps (at least 16 Mi).
• When the suggested request would pass the limit, or memory use is near it, a higher limit is suggested too: the peak plus 50%. Kubernetes doesn’t allow a request above its limit.

What it flags

• Close to OOM: memory peaked within 10% of the limit. The next spike may kill the container.
• Using more than requested: the node may run short, and the pod is evicted earlier.
• Over-requested: the request is at least double the suggestion and at least 100m CPU or 128 Mi more. The summary adds up the requests that could be given back.
• No requests at all: the scheduler can place it anywhere, and it’s evicted first.

Applying a suggestion

Each row copies a command like this one, with the cluster, namespace and container filled in:

kubectl set resources deployment/web -c web --requests=cpu=100m,memory=128Mi

It changes the running workload. If your manifests live in Git (Helm values, Kustomize, Argo CD or Flux), put the same values there, or the next sync puts the old ones back. Review traffic peaks first: seven days include a full week, while 24 hours may miss them.

Runtimes that report usage per pod only

Some container runtimes (Docker through cri-dockerd, as on minikube) give per-pod totals, not per-container numbers. KubeEyes then compares a multi-container workload’s total use with its containers’ requests added up, in one “(all containers)” row.

Questions