← Back to Labs
Service Mesh Traffic Lab
Trace one pod-to-pod call through interception, xDS state, workload identity, route policy, retries, and hop-level telemetry.
Call profileChoose the kind of service-to-service request that is crossing the mesh
Incident modeDecide whether the mesh is seeing a healthy path, a slow canary, or a peer identity problem
Control-plane view
Local proxy uses RDS/CDS/EDS/SDS state for catalogue.prod.svc.cluster.local; the control plane is not forwarding this request live.
Route decision
catalogue.prod.svc.cluster.local matched route policy: header x-user-tier=beta -> subset v2, default timeout 750 ms.
Security result
mTLS peer check expects spiffe://mesh.local/ns/prod/sa/catalogue and presents source identity spiffe://mesh.local/ns/prod/sa/orders.
Resilience result
1 retry on timeout or reset, budgeted for idempotent reads
Step 1 / 6The pod redirects the app socket into the local proxy
The application thinks it is opening a normal service-to-service connection. The pod network rules catch that outbound TCP flow and hand it to the sidecar first.
The app's connect for GET /items/48192 is redirected into the outbound listener on the local proxy before any remote upstream socket exists.
Emit span orders -> catalogue, route=catalogue, attempts=1, peer=spiffe://mesh.local/ns/prod/sa/catalogue.
1. GET /items/48192 -> catalogue-v2
Arrow keys to navigate · R to reset
Tap dots to jump to any step