Cluster assessment
Ranked findings instead of a pod list: crash loops, OOM kills, pods that will never schedule, sizing problems — each with what to do about it.
Capacity and trends
Kubernetes capacity measured against requests, with the history to read it
Scheduling is decided by what pods reserve, not by what they use, so PodSteer shows both on one track and names the gap between them. It samples each connected cluster while the application is open and keeps that history on your machine, and it can draw longer trends from the Prometheus or VictoriaMetrics you already run, sending a query only when you ask for one.
Requests decide what schedules
A cluster can refuse new pods while every usage graph looks calm, because the scheduler counts what pods reserved. PodSteer keeps allocatable capacity, requests, limits and usage as four separate figures, so "requested" and "used" are never folded into one dial you have to second-guess.
The totals leave out what should not be in them: finished pods occupy no node, and a cordoned node offers no pod slots. Efficiency divides what pods use by what they requested, never node usage, which also counts the kubelet, the container runtime and the operating system.
- Rightsizing per workload: reserving far more than it uses, throttled at its CPU limit, or running over its memory request — judged with the same ratio as the cluster-wide waste finding, so the two cannot disagree.
- Node disk occupancy, read from the kubelets themselves.
- A pod's usage is charged to the controller that owns it, not to whatever its labels happen to match.
A missing number is named, not shown as zero
Usage comes from metrics-server, which is optional. When it is absent PodSteer says which of three things is true — not installed, not permitted to read it, or failing — because they need opposite next steps.
"Nothing measured" is kept apart from "no metrics API": a Deployment scaled to zero is not told to install metrics-server. A total that covers only some pods says how many it covers, counted against the pods metrics-server can actually report.
History, sampled while the application is open
Kubernetes reports only the present, so PodSteer keeps its own record: it samples each connected cluster, every 30 seconds by default for the one on screen and less often for clusters in background tabs. The Trend panel says how often, so a sparse stretch is never read as an outage.
The history stays on your machine, for a day, a week or thirty days — or not at all, which also erases what was recorded. It carries no object names.
Your own Prometheus or VictoriaMetrics, when you ask
For trends longer than a session, PodSteer can chart the monitoring backend already in your cluster. It is off by default and set per cluster: On request puts a control on each chart, and When a chart opens sends a query as a chart opens or its range changes. Neither ever queries on the refresh tick.
Queries go through the API server's service proxy on your own credential, as GET requests, so no new host is contacted. The expressions are a fixed set, each aggregated to cluster or node level; there is no query box.
- A backend holding several clusters' series — Thanos, Mimir, Cortex, a VictoriaMetrics cluster — is detected by comparing its nodes with this cluster's, then narrowed to this cluster's nodes or refused, as you choose.
- The backend's line is drawn as its own series beside PodSteer's samples, named in the legend, never spliced into them.
- kube-state-metrics is discovered and explained, never queried.
Be honest
What it does not do.
- It is not a monitoring system. Its own history covers only the time the application was open.
- Without metrics-server there is no CPU or memory usage. There is no kubelet fallback for those, by decision.
- Node disk figures need the nodes/proxy permission. Above 128 nodes they are read in rolling batches and can be minutes old, and the Overview says so.
- Backend charts are cluster and node totals only, and nothing a backend returns is recorded.
- A VictoriaMetrics cluster is read for tenant zero only.
Read next
Topology and traffic
One namespace, several or all of them as one map — every line a relationship Kubernetes has — with observed traffic from Istio, Linkerd, Beyla, Caretta or Hubble.
Multi-cluster
Real tabs, one cluster each; one table across every open cluster; clusters found through your own cloud CLI.