[Bug] Nodes list view shows CPU as "0.0Ki" while Memory works correctly; cluster reports CPU properly

[jcrouseilles]

Describe the bug

In the Nodes list view, the CPU column displays 0.0Ki for every node, regardless of actual CPU usage. The Memory column for the same nodes shows correct values (e.g. 18.0Gi). The CPU value
appears to be formatted with byte units (Ki/Mi/Gi), suggesting a unit-mismatch bug where CPU data (typically in nanocores or millicores) is being rendered through the bytes formatter.

Note that the Memory column works correctly, the node detail view (per-node Metrics tab graphs) renders CPU correctly, and the cluster itself reports CPU correctly through every other channel.

Reproduction steps

1. Connect Freelens to a kubernetes cluster with a healthy metrics-server and a running kube-prometheus-stack
2. Open Catalog → Workloads → Nodes or Cluster → Nodes
3. Observe the CPU column shows 0.0Ki for every node

Expected behavior

Expected: CPU column shows real CPU usage values (cores or millicores).

Actual: CPU column shows 0.0Ki uniformly. Memory column on the same row shows accurate values, so the issue is isolated to CPU rendering in the list view.

Screenshots

Freelens version

1.9.0

Operating system type and version

MacOS 26.5 M3

Installation method

Homebrew Cask

Kubernetes cluster version used with Freelens

1.35.2

Logs

No response

Kubeconfig

No response

Additional context

• Cluster type: OVH Managed Kubernetes (r3-64 flavor nodes)
  • metrics-server: present and reporting normally
  • Prometheus stack: kube-prometheus-stack v84.3.0 (also configured manually in cluster settings → Metrics → prometheus/<prometheus-svc>:9090)

Reproducibility

Persistent. Reproduces across:

• Disconnect / reconnect of the cluster
• Full uninstall + clean reinstall of Freelens (DMG removed, ~/Library/Application Support/Freelens, ~/Library/Preferences/app.freelens.*, ~/Library/Caches/*freelens*, and ~/Library/Saved Application State/*freelens* all wiped before reinstall)
• Two consecutive cluster nodepool shape migrations (b3-32 → r3-64 → r3-64 again) — the bug appeared first right after a drain operation that rescheduled metrics-server to a new pod IP, and persisted
  through subsequent migrations even after we ensured the cluster was fully clean

What we've already verified about the cluster

The cluster reports CPU correctly through every other channel:

$ kubectl --context=<cluster> top nodes
NAME                 CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
thanos-node-14906f   3794m        48%      18250Mi         29%
# ... etc, all values populated correctly

$ kubectl --context=<cluster> get --raw '/apis/metrics.k8s.io/v1beta1/nodes' | jq '.items[0].usage'
{
  "cpu": "3793172185n",     # nanocores — correct
  "memory": "18688656Ki"    # kibibytes — correct (and Memory column renders this fine)
}

metrics-server is 1/1 Running, APIService v1beta1.metrics.k8s.io is Available=True, kubectl top works flawlessly.

The Freelens node detail view → Metrics tab also loads CPU charts correctly. The bug is isolated to the list view column.

[nefelim4ag]

Hmmm, I've switched the autodetected Prometheus metrics endpoint to Thanos with:

apiVersion: v1
kind: Service
metadata:
  name: aperated-prometheus
  labels:
    operated-prometheus: "true"
spec:
  ports:
  - protocol: TCP
    port: 9090
    targetPort: http
  selector:
    app.kubernetes.io/component: query-frontend
    app.kubernetes.io/instance: thanos
  clusterIP: None
  clusterIPs:
  - None
  type: ClusterIP
  sessionAffinity: None
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  internalTrafficPolicy: Cluster

And I experience similar problems.
(where I do have 2 Prometheus replicas for metrics HA).

I have enabled the debug logging in thanos query frontend, to see the queries, and try them out manually.

It seems that cause is a duplicate metric, for example, one with pod_ip (kubernetes/kube-state-metrics#1432) and second one without (or "same" statefulset pod-0 on a different nodes at different times).
The workaround, I guess, is to either use instant metrics instead of the range or explicitly group up metrics as shown below max by (namespace, pod, node) (...):

sum(node_memory_MemTotal_bytes * on (pod,namespace) group_left(node) max by (namespace, pod, node) (kube_pod_info{node=~""}) - (node_memory_MemFree_bytes * on (pod,namespace) group_left(node) max by (namespace, pod, node) (kube_pod_info{node=~""}) + node_memory_Buffers_bytes * on (pod,namespace) group_left(node) max by (namespace, pod, node) (kube_pod_info{node=~""}) + node_memory_Cached_bytes * on (pod,namespace) group_left(node) max by (namespace, pod, node) (kube_pod_info{node=~"")))

If I switch the view to a shorter time window (5min) it works (1.10.0):

Hope that helps someone,
-Timofey

---

As a side note, I think the query error output in the console can be helpful. So, one can run the freelens from cmdline and see the reason, why metrics query failed.

[dex4er]

@claude [model:fable] Plan fix for "0.0Ki" bug in node list view then Opus should implement PR

[claude]

Claude finished @dex4er's task in 3m 48s —— View job • claude/issue-1883-20260702-1221 • Create PR ➔

---

Fix for "0.0Ki" CPU in Nodes list view — done

Todo

• Gather context and locate the offending code
• Root-cause analysis and fix plan (Fable, planning only)
• Implement the fix (delegated to Opus)
• Validate (biome check passed; no tests or snapshots cover this component)
• Commit and push to branch claude/issue-1883-20260702-1221
• Provide PR link

Root cause

The Nodes list CPU column falls back to metrics-server data when the Prometheus range query returns nothing usable (renderUsage in packages/core/src/renderer/components/nodes/route.tsx:135 renders usageText when Prometheus capacity is 0 or missing — exactly the situation described in the comments, e.g. duplicated kube_pod_info series breaking the range query).

NodeStore.getNodeKubeMetrics (store.ts:67) correctly converts the metrics-server CPU value (e.g. "3793172185n" nanocores) to cores (~3.79), but getNodeCpuUsage (route.tsx:120-124) then passed that cores value through bytesToUnitsAligned, a bytes formatter. Any core count below 1024 renders as (cores / 1024).toFixed(1) + "Ki" → "0.0Ki" for every node. Memory works because it genuinely is bytes. The wrong value also leaked into the CPU tooltip when Prometheus does work (route.tsx:147).

Changes (two commits, one per fix)

d9c1a302 — Format node CPU usage in cores instead of bytes in nodes list view
6f910cba — Show N/A for node memory usage when metrics-server data is missing

   getNodeCpuUsage(node: Node) {
     const metrics = this.props.nodeStore.getNodeKubeMetrics(node);

-    return bytesToUnitsAligned(metrics.cpu);
+    return Number.isNaN(metrics.cpu) ? "N/A" : metrics.cpu.toFixed(3);
   }

   getNodeMemoryUsage(node: Node) {
     const metrics = this.props.nodeStore.getNodeKubeMetrics(node);

-    return bytesToUnitsAligned(metrics.memory);
+    return Number.isNaN(metrics.memory) ? "N/A" : bytesToUnitsAligned(metrics.memory);
   }

CPU is now shown in cores with three decimals (e.g. 3.793), matching the pods list CPU column, and N/A is shown when metrics-server data is absent (previously rendered NaN garbage). Biome check passed; no existing tests or snapshots reference these methods.

Per the trigger request, Fable was used only for planning and analysis; the code edits were implemented by an Opus subagent (claude-opus-4-8).

--- | Branch: claude/issue-1883-20260702-1221 | Model: claude-fable-5