Explore your cluster

Getting around

Open Kubernetes (left nav). With several clusters you land on the fleet view — total/healthy clusters, pods, nodes — and cluster cards showing provider, region, version and a source chip (VerOps Agent or OTel). Click a card (or use the Cluster selector) to focus one cluster: six KPI tiles (nodes, pods, services, CPU, memory, active alerts — CPU/memory turn red above 80%), a health chip, a time-range picker, and six tabs. Everything auto-refreshes every 20 seconds; row clicks open a detail drawer.

The tabs

Tab	Use it for	Drawer detail on click
Cluster Overview	Health score, control-plane component status, resource utilization trend, node/pod summaries, recent warnings.	—
Nodes	Status, CPU/memory bars, pods per node, kubelet version; filter by status or master/worker.	Conditions (MemoryPressure, DiskPressure…), allocatable vs capacity, OS/runtime info, labels.
Pods & Workloads	Status, restarts, CPU/memory per pod; filter by namespace or status.	Restart count, node, IP, containers, usage vs requests/limits, labels.
Services & Networking	Type, cluster/external IPs, ports, endpoint counts (red when 0).	Ports table, selector, endpoints, created time.
Storage	Sub-tabs for Persistent Volumes, Volume Claims (with usage %), Storage Classes.	Status, capacity, access modes, usage bar.
Events & Alerts	Events with reason, object, message, count; critical-alerts banner on top.	Full message, involved object, first/last seen.

Common investigations

A pod is crash-looping

1. Open Pods & Workloads; set the Status filter to CrashLoopBackOff, or scan the Restarts column (chips turn orange above 3 restarts, red above 10).
2. Click the pod: the drawer shows restart count, its node, and memory usage against the limit — usage pinned at the limit suggests OOM kills.
3. Switch to Events & Alerts and search the pod name: look for OOMKilled, BackOff or probe failures, and check the Count column for how often.
4. If the pod backs a service, jump to Applications for its traces and errors.

Pods stuck Pending

1. On Pods & Workloads, read the Pending summary card, then filter Status → Pending.
2. In Events & Alerts, find the matching FailedScheduling event — its message names the constraint (insufficient CPU/memory, taints, unbound PVC).
3. Cross-check Nodes: are all nodes near capacity, or is one NotReady? For volume problems, check Storage → Volume Claims for claims stuck Pending.

A node is under pressure

1. On Nodes, scan the CPU/memory bars (red above 80%).
2. Click the node: Conditions shows MemoryPressure / DiskPressure / PIDPressure as True/False chips; Resource Usage compares usage to allocatable and capacity, including pod count vs pod capacity.
3. Back on Pods & Workloads, filter to that node's pods (search the node name) to find the heavy consumers.

What just happened in the cluster?

1. Open Events & Alerts: the banner surfaces the three most recent warning/error events; the table sorts by Last Seen.
2. Filter Type → Warning or Error, and watch the Count column — a high count means it's recurring, not a one-off.

Clusters connected via an OpenTelemetry collector (an OTel source chip) show aggregated metrics; detail drawers and events are richer on clusters running the VerOps agent. See Install the Kubernetes agent to switch or run both.