Dashboards - Kubernetes Search

Kubernetes Search ships a set of dashboards built entirely on its search commands. Because the commands query the API live, the dashboards show the cluster as it is right now - they’re a live console, not a view over stored history. Each dashboard has a cluster picker, so you point it at any cluster you’ve registered, and opens on the first registered cluster rather than waiting for you to choose one. A drilldown into the Pod or Node dashboard keeps the cluster you came from.

A severity, an event type, or a health state is the same colour on every dashboard, and the same as in the Monitoring Kubernetes and Monitoring OpenShift apps: a Warning event is yellow, a Normal event and an ok status green, critical and error red, and info blue.

Some panels read cluster-scoped kinds that the built-in view ClusterRole does not grant: the node and zone panels on Cluster Health, the node panels on Incident Snapshot and System Components, Node special resources and the admission webhook panels on Resource Hygiene, Stuck VolumeAttachments on Incident Snapshot and Networking & Storage, the PersistentVolume and StorageClass panels on Networking & Storage, and most of the Node dashboard. For a credential bound to view alone, each of them shows 403 Forbidden and the panels beside it still load. Bind the k8s-search-cluster-read ClusterRole as well to fill them; see Clusters - Bearer token.

Find them under the app’s navigation, grouped as below.

Overview

Cluster Health is the landing dashboard: live health and inventory for one cluster - node and pod counts, degraded workloads, namespaces under pressure, and the most recent warnings, on one screen.

System Components reports the state of the control plane - API server, etcd, scheduler, and controller-manager - so you can confirm the cluster’s core is healthy before digging into workloads.

Workloads summarizes Deployments, StatefulSets, and DaemonSets and their rollout status, surfacing anything that isn’t fully available.

Troubleshooting

Incident Snapshot is the page to open when something is wrong: a single, dense summary of what’s unhealthy right now - failing pods, recent warning events, and restarts - so you can orient in seconds.

Reliability Troubleshooting drills into the classic failure modes: crash loops and restarts, OOM kills, pending and unschedulable pods, failing probes, image-pull failures, stale pods, and old or failed batch Jobs and CronJobs.

Events is an interactive browser over | k8sevents - filter by namespace, type, reason, and the object an event targets. Its tabs are Triage, Hot Spots, Streams, By Object, and Raw Details.

Severity ranks what killed a workload first. OOM kills, evictions, and node conditions carry their own severities - oom, evicted, node not ready, and node pressure - and rank above scheduling and image pull problems wherever severity is used: the By Object tab’s ordering, the timeline annotations, and the table colouring. Volume problems (FailedMount, FailedAttachVolume, FailedMapVolume, Multi-Attach) have a volume severity of their own.
Hot Spots has an “OOM kills, evictions and node conditions” table listing exactly those events, with the object, reason, occurrence count, and reporting component. It reuses the page’s searches, so it adds no call to the Kubernetes API.
The Object box matches part of a name. It finds any object whose name or namespace/Kind/name label contains what you type. Clicking a row fills a separate Selected Object box, which narrows the page to exactly that object; clear it to widen back out.
Tables name an object as namespace/Kind/name in one column, so a click selects that one object rather than every object sharing its name.

Logs Explorer is an interactive front end to | k8slogs: pick a namespace and pod pattern, set a tail or time window, and read the lines without writing SPL.

Reviews

Resource Hygiene reviews configuration quality across the cluster - containers without CPU or memory requests or limits, ephemeral storage and emptyDir volumes, the special resources nodes offer and pods request (hugepages and extended resources such as GPUs), probe coverage, pod security posture, mutable image tags, pod QoS classes, and admission webhooks without ready endpoints.

Networking & Storage reviews network and storage objects across four tabs: Networking (Services, flagging any without ready endpoints; Ingresses; EndpointSlices), Storage (PersistentVolumeClaims, PersistentVolumes, and StorageClasses), Unused PVCs, and Stalls (stuck VolumeAttachments, claims pending for more than five minutes, and volume mount warnings). The PersistentVolume, StorageClass, and Stuck VolumeAttachments panels read cluster-scoped kinds the built-in view role does not grant; without k8s-search-cluster-read they show the 403 on their own, and the claim panels still load.

The Unused PVCs tab lists the PersistentVolumeClaims no pod has used for at least the time you pick (30 days by default), with their storage class, capacity, and volume mode. It reads the Unused condition Kubernetes records on each bound claim from 1.37 (on 1.36 with the PersistentVolumeClaimUnusedSinceTime feature gate on), whose timestamp says since when:

Idle claims come first, then retained ones - claims left behind by a StatefulSet that was scaled down, which Kubernetes keeps so a scale-up gets its data back. Each group is sorted by capacity times unused days, largest first. Counts above the table give the idle claims, the capacity they hold, the retained claims, and the bound claims with no Unused condition at all.
A claim with no Unused condition - every claim on a cluster before 1.36, or on one with the feature gate off, as it is by default on 1.36 - is never counted as idle.
A pending pod, even one that cannot be scheduled, counts as using its claims; a completed or failed pod does not. The condition is not backfilled, so once a cluster starts recording it, by an upgrade to 1.37 or the gate turned on, every claim’s unused time starts then.
The tab lists StatefulSets to recognize retained claims, so it needs a credential that may list them; without that permission it shows Kubernetes’ refusal and the other tabs are unaffected.

Before deleting a claim, check its volume’s reclaim policy in the Storage tab’s PersistentVolumes table: under Retain, deleting the claim leaves the volume behind.

Details

Pod shows a single pod in depth: its spec and status, per-container state, and the events that reference it - the dashboard equivalent of | k8sdescribe kind=pod/....

Node does the same for a node: capacity and allocatable resources, conditions, the pods scheduled on it, and related events. A condition whose status is Unknown - as every condition is once the kubelet stops reporting the node - reads lost and stays highlighted. Its node picker and the node’s own details read the Node object, so a credential bound to view alone sees 403 Forbidden on most of the page; it needs k8s-search-cluster-read too.

Every dashboard is read-only and runs against the live API on the search head, so opening one is exactly as safe (and as current) as running the underlying command yourself. The dashboards show no Edit button: an app upgrade replaces them, so an edit made in place would be lost. To build your own, start from the Command reference - the bundled dashboards are just SPL over the same five commands.