Istio traffic detection fails for revisioned istiod (e.g. istiod-1-30-1)

[Svm1905]

Radar's Traffic view does not detect Istio when the istiod control plane is deployed under a revisioned name such as istiod-1-30-1, which is common with Istio canary/revision-based installs. In this setup the mesh is fully running and healthy, and Istio metrics (istio_requests_total with full source/destination workload labels) are already available in Prometheus and queryable by Radar, yet the Traffic view reports the source as not detected and instead recommends installing Caretta. I confirmed this on Radar v1.12.1 running in-cluster and verified the same code path exists in v1.13.1 and main.

The root cause is in
istio.go
. The Detect() function looks up istiod by a hardcoded exact deployment name (const istiodName = "istiod") across a fixed namespace list (istio-system, istio, default), calling Deployments(ns).Get(ctx, "istiod", ...). On a revisioned install the Deployment is named istiod-1-30-1, so this Get returns NotFound, every namespace is skipped, and Istio is reported as unavailable — even though the mesh is up and metrics exist. Interestingly, the same function already reads the istio.io/rev pod label to populate the version field, so the code is aware that revisions exist; only the discovery step is revision-unaware.

A straightforward fix would be to discover istiod by label or name prefix rather than an exact name — for example, listing Deployments in the candidate namespaces with label selector app=istiod, or matching a name prefix of istiod- in addition to the exact istiod. This preserves existing behavior for default installs while also supporting revisioned/canary control planes. This matters because revisioned Istio is a standard pattern for safe upgrades, and affected clusters are steered toward installing an eBPF agent (Caretta) despite Istio plus Prometheus already providing everything the Istio source needs. Once detection passes, GetFlows() already resolves service-to-service flows, request rates, and 5xx error rates correctly against the existing Prometheus metrics — verified via direct PromQL.

[Svm1905]

Can anyone please help me out here?

[roylibman]

Confirmed, your diagnosis is exactly right.

Detect() does an exact-name Deployments(ns).Get(ctx, "istiod", ...), so istiod-1-30-1 returns NotFound in all three candidate namespaces and Istio gets reported absent. Same line in v1.12.1, v1.13.1 and main, so your version note holds too.

The rest of what you saw follows from that: with Available=false the source goes into notDetected rather than detected, and the Istio-specific branch in generateRecommendation only fires for a source in detected. So it falls through to the CNI-based recommendation, which is why you get pointed at Caretta with a healthy mesh.

Your suggested fix looks like the right shape. I checked against Istio's chart and app: istiod is set unconditionally, on both the Deployment and the pod template, for default and revisioned installs alike, so a label-based lookup would cover both. One wrinkle: multiple revisions can run at once during a canary upgrade, so whatever replaces the Get has to pick deterministically rather than take the first result. We want to take another look before settling on an approach, though, so I can't promise that's the shape it lands in.

No decent workaround in the meantime, unfortunately. POST /api/traffic/source will set istio active, but reconcileActiveSource reverts it on the next detection pass since istio isn't in the available set.

No firm date I can give you, but we believe we'll have a fix soon. Thanks for tracing it this far, this is about as clear as a bug report gets.

[nadaverell]

Moved this to an issue so it can be tracked and picked up: #1870. It captures your diagnosis, the label-based detection approach (app=istiod), how to pick deterministically when several revisions are running during a canary upgrade, and the test cases. Marked help wanted, so if you'd like to open a PR, it's all yours. Follow-ups on #1870, please.

[Svm1905]

Thank you so much for the fix its working now.

[nadaverell]

great, thanks for the update! keep it coming if you run into any other issues