Rightsizing
Monitoring › Rightsizing compares the CPU and memory each running pod uses with its containers’ requests and limits, in the namespace chosen in the top bar or in every namespace. Everyone sees the tab; it covers the namespaces whose pods you may list and names the ones it skipped. If you may not list pods across the cluster, every namespace means the first 25 you can see, your kubeconfig context’s namespace first, and the page says how many it left out; to pick the ones read, list them under Settings › Clusters › Allowed namespaces. KubeGlass doesn’t know your cloud prices; it shows what you can change.
Where the usage comes from
Section titled “Where the usage comes from”Each container is compared with its own usage. When there is an hour or more of a container’s usage, that usage is the 95th percentile of the last 24 hours, or of as much as there is, so a quiet minute doesn’t shrink a request that a busy one needs. It comes from Prometheus when it has container metrics, and otherwise from the history KubeGlass keeps by sampling metrics-server; see CPU and memory history. History is used only in namespaces whose pod metrics you may read (get on pods.metrics.k8s.io).
For a container with less history, the usage is one reading: metrics-server’s latest sample, or, for people with cluster-wide read access, Prometheus’s CPU rate over the last five minutes and the current memory working set. When the source has only a pod’s total, it counts for a pod with one container, and the containers of a pod with several get none from it.
A note on the page says whether the suggestions use the 95th percentile of each container’s usage over the last 24 hours, or one reading of current usage plus headroom because no container has an hour of history. A row whose container has less history than the rest says how many hours it is based on, such as “Based on 6 hours of usage”.
Pods that have finished (Succeeded or Failed) are left out. When only some pods have usage data the page says how many, and without any it says that KubeGlass couldn’t read live usage.
What it suggests
Section titled “What it suggests”KubeGlass looks at every container of every pod, and takes a workload’s pods together: the pods of a Deployment, StatefulSet, DaemonSet or Job whose container has the same requests and limits get one row per finding, with CPU and memory in it. The row is sized for the most any of those pods uses, since one change to the workload resizes them all, and what it frees counts every one of them. A Deployment’s pods are found from their ReplicaSet’s name and the pod-template-hash label, as kubectl names them. During a rollout, the old and new pods have other settings and get rows of their own. A pod without a controller is a row of its own. When only some of a row’s pods have usage yet, such as a replica that just started, the row is sized on those and says so: “Usage from 1 of 3 pods”:
| Finding | When | Severity | Suggestion |
|---|---|---|---|
| Under-provisioned | CPU or memory usage is above 90% of the limit | Critical | A limit of 1.5 times its usage, for each resource near its limit |
| No requests | The container sets neither a CPU nor a memory request | Warning | Requests of 1.3 times its usage. The container gets no other suggestion |
| Over-provisioned | CPU or memory usage is below half of the request, and lowering the request frees at least 100m of CPU or 128Mi of memory | Info | A request of 1.3 times its usage, for each resource where that is lower than the current request |
| No limits | The container sets neither a CPU nor a memory limit | Info | None; the row says the container can use as much as the node has |
Over-provisioned is informational: a request above use takes room on a node another pod could have, but nothing breaks. Rows that would free less than 100m of CPU and less than 128Mi of memory, over all their pods, aren’t listed, because so little frees no room for another pod and each change is a rollout; the page says how many it leaves out.
Usage is the 95th percentile or the one reading described above. Suggested values are at least 10m CPU and 64Mi memory, rounded up to steps of 10m below one core and 100m above, and to whole Mi below 1Gi and steps of 64Mi above. A container with no usage data gets only the No requests and No limits rows.
The page
Section titled “The page”The cards at the top count the pods analyzed, the workload containers near their limits, without requests and over-provisioned, and the CPU and memory the listed over-provisioned ones would free on all their pods. A count of 0 is grey.
The table has a row for each workload’s container and finding: the workload (a link to it, or to the pod without one) and container, with the namespace, the workload’s kind and how many pods the row is for; the finding and why; then CPU and memory side by side. Each shows what is set now (the limit for a container near it), the suggested value after the arrow, how much is used and what share of the setting that is, and what the suggestion frees. Containers near their limits come first, then those without requests, then the over-provisioned ones by saving, then those without limits. Saving weighs CPU and memory by their share of what the list would free in all, so a container that frees a tenth of both ranks with one that frees a fifth of either. Sort by the workload’s name, or by what a row frees in CPU or in memory, from the column headers; Sort by saving goes back. Filter by finding.