Skip to main content
Live Traffic draws the connections your cluster is actually making: which workloads call which, how much, and which calls fail. There’s no extra component to install - Radar reads whatever traffic source the cluster already runs.
Radar Live Traffic: the Online Boutique workloads as nodes, loadgenerator calling frontend, frontend calling checkoutservice and the other services, edges labelled with connection counts

Online Boutique's traffic: each workload is one node, with the connections it made in the last five minutes

​
Traffic sources

Radar looks for a source when the page opens, in this order:
  1. Hubble (Cilium). Detected via the hubble-relay Service.
  2. Istio. Detected via istiod.
  3. Caretta. Detected via its DaemonSet.
  4. Beyla. Detected via its network-flow metrics in Prometheus.
When more than one is available, switch between them with the source selector above the map. Istio, Caretta and Beyla are read from a Prometheus-compatible backend - auto-discovered, or set with --prometheus-url / traffic.prometheusUrl.

​
Reading the map

  • Nodes are workloads. A Deployment, StatefulSet, DaemonSet or CronJob is one node however many replicas it runs. Turn off Group by Workload to see one node per pod.
  • Edges carry the number of connections (Hubble, Caretta) or requests per second (Istio, Beyla) in the selected window. The legend explains the rest: arrows show who opened the connection, and errors (5xx), drops and the busiest paths each have their own style.
  • Filters on the left narrow what’s drawn: the time window (1 minute to 1 hour), namespaces, Hide System for infrastructure traffic, Hide External, and grouping for cluster add-ons and Internet addresses.
  • The flow list under the map shows individual records - source and destination pod, port, HTTP details when the source has them, and the verdict. Select a node or an edge and the list loads the records behind it.

​
Focus on a workload

To answer “what does this service talk to”, focus on it. The map then shows only that workload and the workloads it exchanges traffic with, whatever their namespace.
  • Press /, or click Focus on a workload above the map, and search by name.
  • Or select a node and focus on it from its details.
  • Or, on a workload’s own page, click Live traffic in the header. The link appears once Radar has detected a traffic source.
The focus is part of the page URL, so you can share a link to it.
Radar Live Traffic focused on checkoutservice: frontend calls it, and it calls the shipping, product catalog, currency, payment and email services; the flow list shows the records for the selected workload

Focused on checkoutservice: its caller, the services it calls, and the records behind it in the flow list

​
Large clusters

Live Traffic is built to stay responsive on clusters with thousands of pods:
  • Traffic you’ve hidden (system namespaces, host traffic) is filtered out at the source rather than in the browser.
  • Each refresh keeps a bounded number of the newest flows. When a busy cluster produced more than that in the window, the map says how much of the window it covers.
  • When the map would be too large to lay out, Radar lists the connections instead, failures first, and offers ways to narrow it: pick a namespace, or focus on a workload. A map that’s large but still drawable can be shown with Draw anyway.
Radar Live Traffic explaining there is too much traffic to draw at once, with buttons to narrow to a namespace or focus on a workload, above a table of connections sorted by failures

Too many connections to draw: the map is replaced by its connections, problems first, with ways to narrow it

​
Dropped flows

Hubble is the only source that reports drops. Expand a dropped flow to see the reason Hubble reported, when it gave one. For policy drops, Radar also checks the current Kubernetes NetworkPolicies against that connection - see Why was this flow dropped?.

​
When no source is installed

Live Traffic shows a setup guide instead of the map: what Radar detected about the cluster, which sources fit it, and how to install one. Once a source is running, the map appears. The options:
  • Cilium with Hubble - the most common deployment.
  • Istio - service mesh.
  • Caretta - eBPF, no CNI dependency.
  • Beyla - eBPF, no CNI dependency. Radar reads Beyla’s network-flow metrics from a Prometheus-compatible backend, so installing Beyla alone is not enough: its network metrics feature must be on and scraped into a backend Radar can reach (auto-discovered or prometheusUrl). If your scrape job is not named the default way, set --beyla-job-selector (see CLI).

​
RBAC for Hubble TLS

If your Hubble Relay uses TLS (the default in modern Cilium), Radar needs to read the relay’s TLS certs. The Helm chart enables this by default with rbac.traffic: true. Set it to false to disable Hubble support entirely.

​
Privacy

The map shows aggregates - connections, request rates, status. The flow list shows what the source reports for each flow: with Hubble L7 visibility (Cilium HTTP-aware policies) that includes the HTTP method, path, status and an allowlist of headers; otherwise just L4. Radar never captures or displays request bodies.

​
See also

  • Workload metrics - request rate, HTTP errors, latency and resource pressure for one workload. These charts are separate from the traffic map: Beyla application metrics can support them without network-flow collection, and CPU/memory do not require a traffic source.
  • Topology view - its traffic mode shows the routing your manifests declare (Ingress, Service, Pod); Live Traffic shows what actually flows.
  • Configuration files - prometheusUrl for out-of-cluster metrics.
  • Integrations & CRDs - which mesh / CNI integrations are recognized.