Skip to main content

k8X Nodes

The Nodes tab lists every node across the clusters in scope, with the conditions, capacity and utilization that decide whether a node can still take work.

Node table with Node, Status, Role, Zone, Pods, CPU %, Mem %, Kubelet, and Age columns beside a filters sidebarNode table with Node, Status, Role, Zone, Pods, CPU %, Mem %, Kubelet, and Age columns beside a filters sidebar

Filters​

FacetUse it to...
ClusterNarrow to one cluster's nodes
StatusIsolate Ready, NotReady, MemoryPressure, DiskPressure, or PIDPressure nodes
RoleSeparate control-plane nodes from workers. Only control-plane nodes carry a role label, so workers show no value
ZoneCompare availability zones
Instance typeCompare machine types

The search box matches node name, role, zone and instance type.

Node List​

The CPU utilisation and Memory utilisation charts above the table cover the top five nodes only, so a node further down the table will not have a series there.

ColumnDescription
NodeThe node's name
StatusReady, or NotReady in red, or a pressure condition in orange
RoleThe node's role label, or — for a worker
ZoneThe node's zone, or —
PodsRunning pods over allocatable pods, as 31/58
CPU %Sparkline and latest CPU utilization against allocatable. Orange at 80%, red at 95%
Mem %Sparkline and latest memory utilization against allocatable. Orange at 75%, red at 90%
KubeletThe kubelet version, or —
AgeHow long the node has been in the cluster

Rows are sorted by CPU utilization by default.

If Pods shows a bare count rather than 31/58, the collector is not reporting pod capacity. Add pods to allocatable_types_to_report - see Before You Start. Role, Zone, Kubelet and Age come from node object snapshots, so if all four are — across every row, the k8sobjects receiver is not collecting nodes.

Node Details​

Select a node to open its detail panel.

Node detail panel showing Conditions, Committed, Taints, Pods on this Node, Recent Events, and Host sectionsNode detail panel showing Conditions, Committed, Taints, Pods on this Node, Recent Events, and Host sections

Conditions​

One row per condition the collector reports - Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable. Each reads OK, or Under pressure with a ▲ when the condition is firing.

Committed​

How much of the node is already promised to the pods on it, which is what the scheduler actually reasons about:

  • CPU requested - 12.50 / 16.00 cores
  • Memory requested - 41.2 / 62.0 GiB
  • Pods - 31 / 58

This is requests against allocatable, not usage against allocatable. A node can sit at 30% CPU usage and still refuse new pods because its CPU requests are fully committed. When a row reads Not collected, the container request metrics are not enabled on the collector.

Taints​

None — this node accepts any workload., or one line per taint as key=value:Effect. This is the first thing to check when a DaemonSet is not running everywhere.

Pods on this Node​

Every pod scheduled here, unhealthy pods first, then alphabetical, each with its namespace and status.

Recent Events​

Kubernetes events about this node in the selected window, each with its reason, a ×N count when it repeated, its age, and its message. Warning reasons are highlighted.

Host​

Instance type and Kubelet, the two hardware and version facts that explain a node behaving differently from its peers.

Use Cases​

Diagnosing a Node That Stopped Taking Pods​

  1. Filter Status to the pressure conditions, or look for orange in the Status column
  2. Open the node and read Conditions to confirm which pressure is firing
  3. Check Committed - if CPU or memory requests are near allocatable, the node is full by request even if usage looks modest
  4. Check Taints for something added recently
  5. Read Recent Events for the scheduler's own account

Finding Why a DaemonSet Skips a Node​

  1. Open the node the DaemonSet is missing from
  2. Read Taints - a taint with no matching toleration is the usual cause
  3. Cross-check the DaemonSet's Node Coverage section on the Workloads tab, which names the gap and its reason

Comparing a Slow Zone or Instance Type​

  1. Filter by Zone or Instance type
  2. Compare CPU % and Mem % across the filtered set
  3. Open an outlier and check Host to confirm the machine type, then Pods on this Node for what it is actually running
  • Getting Started - Prerequisites and health thresholds
  • Clusters - Cluster-level capacity these nodes roll up into
  • Workloads - The pods scheduled onto these nodes
  • Events - Full event stream, including scheduling failures
Last updated on
Was this page helpful?