Kubernetes Microservices with Istio

What this diagram shows

This diagram illustrates a production Kubernetes microservices architecture with Istio service mesh. Traffic enters through the Istio Ingress Gateway, where routing rules and authentication policies are defined. Sidecar proxies (Envoy) inject into each pod and intercept all network traffic, enforcing mutual TLS encryption between services. Traffic policies implement canary deployments by gradually shifting percentages of requests to new versions. An observability stack captures metrics, traces, and logs from sidecars and applications, feeding into monitoring tools for real-time visibility. The flow shows how requests traverse ingress, route through configured virtual services, get load-balanced across destinations, and generate telemetry that flows to collection and analysis platforms.

Key components

• Istio Ingress Gateway — Acts as the entry point for external traffic, exposing services outside the cluster and applying initial routing rules and authentication.
• VirtualService — Defines routing logic for traffic, including weight-based traffic splitting for canary deployments and destination rules.
• Envoy Sidecar Proxy — Injected into each application pod, intercepts all inbound and outbound traffic to enforce mutual TLS and apply policies.
• DestinationRule — Configures load balancing policies, connection pools, and TLS settings for communication between services.
• Prometheus Metrics Scraper — Collects metrics from Envoy sidecars and applications to track latency, error rates, and request volumes.
• Jaeger Distributed Tracing — Captures request flows across services, showing end-to-end latency and identifying bottlenecks in the call chain.
• Kiali Observability Dashboard — Visualises the service mesh topology, traffic flows, and health status in real-time based on collected metrics and traces.

When to use it

Use this diagram when documenting a production Kubernetes environment requiring service-to-service communication security, traffic management, and observability. It is appropriate for organizations adopting service mesh patterns, implementing canary releases, or demonstrating multi-service deployments with mTLS enforcement. It also suits architecture reviews, team onboarding, and capacity planning discussions where understanding traffic flow and observability is critical.

Common mistakes

• Neglecting to show sidecar proxy injection and assuming traffic is directly routed, which misses the core mesh enforcement mechanism.
• Omitting the observability stack, making the diagram incomplete as visibility into mesh behaviour is essential to service mesh value.
• Treating canary traffic splitting as a simple binary switch instead of showing it as a percentage-weighted traffic policy implementation.

Adapting it to your system

Replace the generic microservice names (Cart Service, Payment Service, Order Service) with your actual application services. Add your specific container registries, persistent storage backends, or external APIs that your services depend on. Modify routing percentages in VirtualServices to match your actual canary rollout increments. Adjust the observability stack to your chosen backend: substitute Prometheus with Datadog or New Relic, replace Jaeger with Zipkin, or swap Kiali for custom dashboards. Include your namespace layout and ingress domain names if multi-tenant or multi-environment isolation matters.