Cluster assessment

A Kubernetes client that tells you what is wrong

PodSteer opens a cluster on an assessment, not a list. It reads the cluster's own state and ranks what is wrong — crash loops grouped by the workload they belong to, pods nothing will ever schedule, containers killed for memory — and every finding says what to do about it.

Download PodSteer All features

Findings, not fields

Every other client in this category shows you the fields and leaves the conclusion to you. PodSteer draws the conclusion, in the Go code where it can be argued with in a test: a container that exited 137 is called OOMKilled only when the kubelet also said so, and otherwise reads as a grace period running out, because the two need opposite fixes.

A correctly configured pod produces no findings at all. A panel that always has something to say is one people stop reading.

PodSteer's cluster overview with its findings open under a banner reading Needs attention, 4 critical and 5 warning findings. Listed: an image that cannot be pulled for two pods of storefront/reviews, two unschedulable pods of storefront/search-indexer, CrashLoopBackOff for the image-resizer deployment, an unschedulable Trivy scanner job, and the start of a warning about failing startup probes. Each finding says what the state means. — **Findings, named by the workload.** Each finding names the workload it belongs to and says what the state means, before a single pod has been opened.

What it looks for

Crash loops, image pull failures and containers stuck starting, grouped by the workload that owns them.
Pods that can never schedule, and why — requests larger than any node, or constraints nothing satisfies.
OOM kills and restarts, with the last termination explained rather than printed as an exit code.
Rightsizing: workloads that reserve far more than they use, are throttled at their CPU limit, or run over their memory request.
Capacity measured against requests, not usage — the number that decides whether a pod schedules.
APIs your cluster still writes through that the next Kubernetes version removes, found from who writes them, not from object counts.
Kubernetes versions past the end of their support window.
Images named by a tag that can be repointed rather than by a digest — and, in the detail panel, a warning on any image left on :latest.

Honest about what it could not see

Metrics are optional, and when they are missing PodSteer says why — no metrics-server installed, not permitted to read it, or failing — because those need different fixes. A figure it could not measure says so instead of reading as zero.

Applications and logs

An application's Map tab draws its workloads, their ReplicaSets, Jobs and pods, the Services that select them, its Ingresses, and the ConfigMaps, Secrets, PersistentVolumeClaims and ServiceAccounts they share. Only relationships that exist in the cluster are drawn.
Its Logs tab reads all of the application's pods in one view, each pod in its own colour.
Any log can be filtered by level, including logs with no recognisable level, with a count on each chip, and a volume histogram shows where the lines cluster: click a bar to jump there.

The storefront-web application's Map tab, maximised: its Deployment owning four ReplicaSets, the current one owning three pods, the storefront-web Service selecting those pods, and the ConfigMap storefront-web-settings all three pods use, under a line saying the map is everything labelled app.kubernetes.io/instance=storefront-web plus what those objects own. — **An application, as a map.** Membership is the application's own label; every line is a relationship the cluster holds.

The storefront-web application's Logs tab, maximised and narrowed to its web container: access-log lines from its three pods interleaved, each line prefixed with its pod's name in that pod's own colour, a volume histogram across the top, and level chips showing these lines carry no recognisable level. — **Every pod of an application, in one log.** All of an application's pods in one stream, told apart by colour.

New in v0.3.0

Rightsizing findings and the upgrade-impact check.
A session timeline per object: events, findings appearing and clearing, and every change PodSteer itself made.
Optional desktop notifications when a new critical finding appears — off by default.
A detail panel that reads in the manifest's own order, with CronJob schedules in words and environment values resolved.
Logs parsed as JSON or logfmt, and a minimap on a maximised log that marks where every filter match falls.

A list of deployments in the storefront namespace with checkout open in a detail panel: three replicas desired, current, ready and available, then the pod template with the nginx image, CPU and memory requests and limits, probes, mounts and six environment variables with their values, including the pod's namespace and version, a currency, and a database password shown masked. — **The detail panel, in the manifest's order.** Environment values are shown as the container sees them, and a password stays masked.

A payments-api pod's logs maximised, about a thousand lines of INFO, WARN and ERROR entries filtered for the word declined: 31 matches, one highlighted in the text and all of them marked as orange lines down a minimap at the right-hand edge, under a volume histogram of the lines over time and chips counting them by level. — **Logs with a minimap.** A filter marks every match on the minimap, so you can see where the declined payments fall before scrolling to them.

Be honest

What it does not do.

It is not a monitoring system. Its history is sampled only while the application is open and kept on your machine.
The upgrade check is a hand-compiled table of Kubernetes deprecations: an API it does not cover produces no finding rather than a guess.
The session timeline lives in memory and goes when the tab closes.
An application is the set of objects carrying one app.kubernetes.io/instance label, plus what they own; an object that belongs to it but lacks the label is not on its Map.
The application Logs tab reads at most 40 streams at once.
Clusters in a background tab are sampled less often than the one on screen, and the Trend panel says how often, so a sparse stretch is not an outage.