Skip to main content
The Kubernetes section lists the clusters, nodes, namespaces, pods and containers that sent telemetry in the selected time range, with counts and resource usage for each. It is built from your telemetry, not from the Kubernetes API. aiAxonIQ never connects to your cluster’s control plane. Every row is “something that reported from this pod (or node, or cluster) in the window”, which decides both what the section can show and what it cannot.
Before you start. Install a Collector in the cluster — see Send data from Kubernetes. For traces from workloads without changing their code, see Zero-code instrumentation on Kubernetes.

​
Where the rows come from

Every tab groups metrics by the OpenTelemetry resource attributes below. A metric that does not carry the attribute a tab groups by does not appear on that tab. Pods are keyed by their uid, not their name. A Deployment that rolls reuses pod names, and two pods with the same name in different namespaces are two different pods — both appear as separate rows. The Namespaces tab is the one that joins three signals: the pod and service counts come from metrics, and the log, span and error counts come from logs and spans carrying the same k8s.namespace.name. A namespace appears when it has metrics; one that has metrics but no traces shows zero spans rather than disappearing.
Set k8s.cluster.name yourself. A cluster does not report its own name in its telemetry, so the Clusters tab stays empty until your Collector adds it — and without it, two clusters reporting into one organization cannot be told apart. Add it on every collector in the cluster, for example with a resource processor, and include the processor in each pipeline:
Nodes, pods and namespaces do not depend on it, and still appear without it.

​
Container CPU and memory

The CPU, Memory and Memory used columns average these metrics over the window: These are the names the Collector’s docker_stats receiver emits. A container that reports other metrics still appears, with a dash in these columns rather than a zero — a dash means “not measured”, not “idle”.

​
Every count describes the window

The numbers here are counts of what reported, over the selected time range:
  • Pods on a cluster is the number of distinct pods that sent a metric in the window, not the number running now. Narrow the range and it drops.
  • A pod that stops reporting disappears from the list. It is not shown as unhealthy, because there is no source here that could say it is unhealthy.
  • Last seen is the newest sample from that row. Use it to tell a quiet pod from one that has gone.

​
What this section cannot show

Some Kubernetes facts are not telemetry — they live only in the Kubernetes API, which aiAxonIQ does not read. The section has tabs for four of them, and each says the API does not serve it yet instead of showing an empty table: For the same reason no tab shows a pod’s phase, its restart count, a node’s capacity or a cluster’s version. If your Collector sends cluster metrics that carry those numbers, you can chart them from the Metrics section.

​
Troubleshooting

The Clusters tab needs k8s.cluster.name on your metrics. If Nodes or Pods has rows and Clusters does not, the cluster name is the missing piece — add it as shown above. If every tab is empty, no metric with Kubernetes attributes has arrived; check the Collector is running and its metrics pipeline exports to aiAxonIQ.
Container rows need metrics carrying container.id, and on this tab also k8s.pod.name. Containers on a plain Docker host with no Kubernetes attributes appear under Infrastructure instead — see Infrastructure and Kubernetes.
The counts come from logs and spans that carry k8s.namespace.name. Enable the Kubernetes attributes processor on the logs and traces pipelines as well as metrics, so all three signals are stamped.
No sample of the metric that column reads arrived for that container in the window. See Container CPU and memory for the metric names.
The count is pods that reported in the selected window. Widen the range, and check that every node runs the Collector — a node without one reports nothing.

​
Next

Send data from Kubernetes

Install the Collector in your cluster.

Zero-code instrumentation on Kubernetes

Traces from workloads without code changes.