Traffic management controls ingress and egress requests across microservices, including routing, distribution between application versions, delays, and injected faults. In a service mesh, proxies handle these controls separately from application logic, so developers can change traffic behavior without modifying code. section 4.2 section 4.3.2
Istio traffic management supports these operational controls:
- Ingress exposes services outside the mesh through an Istio gateway, using TLS or mutual TLS. section 4.3.2
- Egress routes outbound traffic to external systems, performs outbound TLS, and can use an HTTPS proxy. section 4.3.2
- Request routing and traffic splitting direct requests among service versions or migrate traffic gradually between them. section 4.3.2
- Fault injection adds configurable HTTP delays or status-code faults to expose application responses to unexpected failures. section 4.3.2
A sidecar proxy commonly manages each microservice’s inbound and outbound traffic as a separate process with the service’s lifecycle. A proxyless design can instead send telemetry directly to the control plane. Centralized control supports multicluster and multicloud service meshes, while the operational complexity of Istio can make troubleshooting difficult. section 4.2 section 4.0
Progressive version migration with failure testing
Route one user to a new application version while sending other requests to the current version, then inject an HTTP delay or fault to verify how the application handles the failure. section 4.3.2
Table 4.1 Istio traffic management features (view table figure)
Use the feature table to compare ingress, egress, request routing and splitting, and fault injection. section 4.3.2
