How would you debug a Service routing failure differently if you were using a service mesh like Istio instead of plain kube-proxy-based Services?

Plain kube-proxy routing failures are diagnosable through Kubernetes' own objects (Service, Endpoints, kube-proxy rules). A service mesh adds an entirely separate control plane and per-Pod sidecar proxy that traffic actually flows through — meaning a routing failure now needs to consider whether the sidecar is even injected and healthy, whether Istio's own traffic-management resources (VirtualService, DestinationRule) are correctly configured, and whether mTLS/authorization policies are blocking the request — a genuinely different, mesh-specific set of things to check beyond plain Service/Endpoints correctness.

Without a mesh, traffic between Pods flows through kube-proxy's kernel-level rules (iptables or IPVS), directly implementing whatever the Service/Endpoints objects declare — the troubleshooting surface is Kubernetes' own native objects, well-documented and directly inspectable.

With Istio (or a similar mesh), a sidecar Envoy proxy is injected into each Pod, and traffic between meshed Pods actually flows through these sidecars rather than directly via kube-proxy alone — the sidecars intercept traffic and apply the mesh's own routing, retry, and security policies before it reaches the destination Pod's actual application container. This introduces several mesh-specific things to check that don't exist in the plain-Service world:

Sidecar injection and health: is the Envoy sidecar actually present and running in both the source and destination Pods (kubectl get pod -o jsonpath checking container count, or istioctl proxy-status)? A Pod missing its expected sidecar (injection wasn't enabled for that namespace, or a Pod was created before injection was configured) behaves differently from a Pod with a sidecar that's present but unhealthy.

Istio traffic-management resources: VirtualService and DestinationRule resources can override or further route traffic beyond what the plain Service/Endpoints objects declare — a VirtualService routing rule sending traffic to an unexpected subset, or a DestinationRule defining subsets that don't match any actual Pod labels, can cause traffic to fail or go somewhere unintended even though the underlying Service/Endpoints are perfectly correct.

mTLS and authorization policy: Istio commonly enforces mutual TLS between meshed services and can enforce fine-grained AuthorizationPolicy rules — a request being correctly routed at the network level but rejected due to an mTLS handshake failure or an authorization policy denying it looks like "the destination isn't reachable" from the caller's perspective, but the actual cause is entirely at the mesh's security-policy layer, not routing at all.

Envoy-specific diagnostics: istioctl proxy-config and Envoy's own admin interface provide visibility into exactly what routing/cluster configuration a specific sidecar has actually received and is using — the mesh-native equivalent of checking Endpoints, but requiring different, mesh-specific tooling.

The overall shift: plain-Service debugging stays within Kubernetes' native object model; mesh debugging requires layering in the mesh's own control-plane state, sidecar health, and traffic/security policy resources as additional, mesh-specific things that can each independently cause a routing-looking failure.

• Plain kube-proxy routing failures are diagnosable through native Kubernetes objects (Service, Endpoints); a mesh adds an entirely separate layer of control-plane state and per-Pod sidecar behavior.
• Sidecar injection/health, VirtualService/DestinationRule configuration, and mTLS/authorization policy are all mesh-specific things that can cause a routing-looking failure independent of whether the underlying Service/Endpoints are correct.
• A request failing due to an mTLS or authorization policy issue can look identical to a routing failure from the caller's perspective, despite being an entirely different root cause.
• istioctl proxy-status and istioctl proxy-config are the mesh-native equivalent diagnostic tools to checking Endpoints in the plain-Service case.

• Istio: Debugging Envoy and Istiod
• Istio: Traffic Management concepts
• Kubernetes Docs: Service