<p>I have two Istio clusters using a replicated control plane with Kiali running. In each cluster I have two applications which interact, but I don't see the traffic between them in the Kiali dashboard. Instead, the traffic shows as going through the Passthrough Cluster. </p>

<p>The application's interact using the kubernetes service name, and they are interacting correctly, it's just not showing correctly in Kiali.</p>

<p>Any thoughts as to what might be the problem? Or is this an expected behaviour (I'm still new to Istio).</p>

the_witch_king_of_angmar
<p>As far as I know this is an expected behaviour when you use Passthrough option. Check below istiobyexample link, which shows exactly how it works.</p>
<hr />
<blockquote>
<p>When <strong>ALLOW_ANY</strong> is enabled, Istio uses an Envoy cluster called PassthroughCluster, enforced by  sidecar proxy, to monitor the egress traffic.</p>
</blockquote>
<hr />
<p>Take a look at kiali <a href="https://kiali.io/faq/graph/#passthrough-traffic" rel="noreferrer">documentation</a> about that</p>
<h2>Why do I see traffic to PassthroughCluster?</h2>
<blockquote>
<p>Requests going to PassthroughCluster (or BlackHoleCluster) are requests that did not get routed to a defined service or service entry, and instead end up at one of these built-in Istio request handlers. See Monitoring Blocked and Passthrough External Service Traffic for more information.</p>
<p>Unexpected routing to these nodes does not indicate a Kiali problem, you’re seeing the actual routing being performed by Istio. In general it is due to a misconfiguration and/or missing Istio sidecar. Less often but possible is an actual issue with the mesh, like a sync issue or evicted pod.</p>
<p>Use Kiali’s Workloads list view to ensure sidecars are not missing. Use Kiali’s Istio Config list view to look for any config validation errors.</p>
</blockquote>
<hr />
<p>And an <a href="https://istiobyexample.dev/monitoring-egress-traffic/" rel="noreferrer">example</a> on <a href="http://istiobyexample.dev" rel="noreferrer">istiobyexample.dev</a>.</p>
<h2>Option 1 - Passthrough</h2>
<blockquote>
<p>To start, let's use an Istio installation with the default ALLOW_ANY option for egress. This means that idgen's requests to httpbin are allowed with no additional configuration. When ALLOW_ANY is enabled, Istio uses an Envoy cluster called PassthroughCluster, enforced by idgen's sidecar proxy, to monitor the egress traffic.</p>
<p>An Envoy cluster is a backend (or “upstream”) set of endpoints, representing an external service. The Istio sidecar Envoy proxy applies filters to intercepted requests from an application container. Based on these filters, Envoy sends traffic to a specific route. And a route specifies a cluster to send traffic to.</p>
<p>The Istio Passthrough cluster is set up so that the backend is the <a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#original-destination" rel="noreferrer">original request destination</a>. So when ALLOW_ANY is enabled for egress traffic, Envoy will simply “pass through” idgen's request to httpbin.</p>
<p>With this configuration, if we send recipe ID requests through the IngressGateway, idgen can successfully call httpbin. This traffic appears as PassthroughCluster traffic in the Kiali service graph - we'll need to add a ServiceEntry in order for httpbin to get its own service-level telemetry. (We'll do this in a moment.)</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/BjrrN.png" rel="noreferrer"><img src="https://i.stack.imgur.com/BjrrN.png" alt="enter image description here" /></a></p>
<blockquote>
<p>But if we drill down in Prometheus, and find the istio_total_requests metric, we can see that PassthroughCluster traffic is going to a destinationservice called httpbin.org.</p>
</blockquote>
<p><a href="https://i.stack.imgur.com/q8e1B.png" rel="noreferrer"><img src="https://i.stack.imgur.com/q8e1B.png" alt="enter image description here" /></a></p>
<hr />
<p>Hope you find this useful.</p>
