Istio is the most widely adopted service mesh in 2019. Understanding its architecture is prerequisite to deploying it in production without surprises.
The data plane: Envoy proxies
The Istio data plane consists of Envoy proxy sidecars injected into every pod. Envoy intercepts all inbound and outbound pod traffic transparently via iptables rules. The Envoy proxy handles: connection management, load balancing, circuit breaking, retries, mTLS, and telemetry generation. The application sees a localhost connection to Envoy; Envoy handles the actual service-to-service connection. The application does not know the mesh exists.
The control plane in 2019
In Istio 1.x through 1.4, the control plane consists of multiple components: Pilot (configuration and service discovery), Citadel (certificate authority), Galley (configuration validation), and Mixer (policy enforcement and telemetry). These components communicate via gRPC to push configuration to the Envoy proxies. The multi-component control plane was simplified in Istio 1.5 (2020), but in 2019 production operators manage the full multi-component deployment.
Traffic management with VirtualService
Istio VirtualService and DestinationRule resources configure the Envoy proxies for traffic management. A VirtualService defines routing rules for a service: route 10% of traffic to subset v2, the remainder to subset v1. A DestinationRule defines the subsets (based on pod labels) and load balancing policy (round-robin, least connections, consistent hashing). The combination enables canary deployments, A/B testing, and fault injection without application code changes.
Mutual TLS configuration
Istio's PeerAuthentication resource controls the mTLS mode for workloads: PERMISSIVE (accept both mTLS and plaintext, for migration), STRICT (require mTLS), and DISABLE (plaintext only). The PERMISSIVE to STRICT migration is the standard adoption path: enable PERMISSIVE, observe that all mesh traffic is using mTLS (via Kiali's traffic graph), then switch to STRICT to prevent plaintext traffic. AuthorizationPolicy resources define which services can communicate with which.