How does gRPC handle service mesh integration (Envoy, Istio)?

gRPC integrates natively with service meshes through the xDS protocol (the API used by Envoy and implemented by Istio/Linkerd control planes). Integration patterns: (1) Sidecar proxy (Envoy) — Istio injects an Envoy proxy alongside each pod. gRPC traffic passes through Envoy, which provides mTLS, circuit breaking, retries, distributed tracing, and observability — no application code changes needed; (2) Proxyless gRPC — gRPC's built-in xDS support allows the gRPC client to directly communicate with the control plane (Istio/Traffic Director) without Envoy, receiving routing, load balancing, and security policies natively. This eliminates the sidecar overhead; (3) gRPC-specific features in Envoy — Envoy understands gRPC semantics: it transcodes between gRPC and JSON/HTTP, understands gRPC health checks, and handles gRPC-level retries (vs. TCP-level retries). The xDS integration enables gRPC to participate fully in service mesh observability and traffic management without being a black box.