Kubernetes troubleshooting

Why are node CPU and memory missing?

Published · Fortem engineering

First separate what is missing. Node names, instance type, pool labels and allocatable CPU/RAM come from Kubernetes Node objects. Current CPU/RAM usage comes from the optional Metrics API. A missing usage value is not zero—and does not mean the node has no load.

Run four read-only checks

Replace YOUR_CONTEXT with the exact context shown in Fortem. Do not rely on kubectl's current context if you switched clusters in the browser.

kubectl --context YOUR_CONTEXT auth can-i list nodes
kubectl --context YOUR_CONTEXT auth can-i list nodes.metrics.k8s.io
kubectl --context YOUR_CONTEXT top nodes
fortem --doctor --context YOUR_CONTEXT

These commands only query authorization, metrics and Fortem readiness. They do not change cluster objects. Fortem doctor reports optional metrics separately from core readiness.

Read the result

Node list: no

The identity cannot list cluster-scoped Node objects. Fortem cannot show node inventory, capacity or pool labels. A cluster administrator would need to grant the read; a namespace Role alone cannot cover Nodes.

Metrics list: no

Node inventory and allocatable capacity may still appear, but observed usage is unavailable. The identity needs permission to list nodes.metrics.k8s.io.

Both: yes; top fails

Authorization is not the whole problem. The aggregated Metrics API may be unhealthy, absent, or returning incomplete samples. Check the actual kubectl top nodes error; do not infer utilization from Node capacity.

All work; UI empty

Confirm that Fortem and kubectl used the same context, refresh the Nodes page, and compare the doctor result. Send a sanitized doctor output and Fortem version when reporting a mismatch; omit kubeconfig and credentials.

What this does not prove

A successful Metrics API check does not guarantee a fresh sample for every node. kubectl top shows recent resource consumption intended for autoscaling signals, not a historical graph or a billing source. Pod requests are scheduler reservations from Pod specs, not measured usage. Fortem keeps capacity, requests and observed usage separate; see the resource-source map.

On GKE, Fortem reads node-pool grouping from the standard cloud.google.com/gke-nodepool Node label. It does not need Google Cloud API access for that view. GKE login can succeed while Kubernetes RBAC still denies a read.

Sources and scope

Checked September 24, 2026. Commands were verified against the Fortem implementation and upstream documentation; no reader cluster was accessed for this article.

Check the same context in Fortem.

Start read-only, run doctor, and inspect node capacity separately from current usage. Begin with the synthetic demo if you do not have cluster access yet.

or install yourself

Local install · read-only first · no Helm chart