liminfoIstio Service Mesh Reference
Free reference guide: Istio Service Mesh Reference
About Istio Service Mesh Reference
The Istio Service Mesh Reference is a hands-on cheat sheet for engineers working with Kubernetes service meshes. It covers the four primary resource categories in Istio: Traffic management resources (VirtualService, DestinationRule, Gateway, ServiceEntry, Timeout, Retry, and Fault Injection), Security resources (PeerAuthentication for mTLS, AuthorizationPolicy for RBAC-style access control, and RequestAuthentication for JWT verification), Observability integrations (Kiali for mesh visualization, Jaeger for distributed tracing, and Prometheus for metrics collection), and Configuration resources (Sidecar scope restrictions and EnvoyFilter for low-level proxy tuning).
This reference is aimed at DevOps engineers, platform engineers, and site reliability engineers who configure and troubleshoot Istio deployments on Kubernetes clusters. Every entry includes a working YAML snippet so you can copy-and-paste directly into your manifests without searching through the official documentation. Traffic shaping patterns like percentage-based routing, weighted load balancing, circuit-breaking via outlier detection, and resilience testing via fault injection are all represented.
The reference is organized into four filterable categories — Traffic, Security, Observability, and Configuration — making it straightforward to jump directly to the area you need. Whether you are hardening a mesh with STRICT mTLS, debugging latency issues with Jaeger spans, or tuning connection pools in a DestinationRule, every common task is covered with a concrete, copy-ready example.
Key Features
- VirtualService traffic routing rules with URI prefix matching and weighted destinations
- DestinationRule connection pool, outlier detection, and load-balancing policy examples
- Gateway HTTPS configuration with TLS credential references for ingress traffic
- PeerAuthentication mTLS modes: STRICT, PERMISSIVE, and DISABLE with namespace scope
- AuthorizationPolicy source principal and HTTP method access control rules
- RequestAuthentication JWT issuer and JWKS URI configuration for token validation
- Fault injection YAML for delay and abort scenarios with percentage-based targeting
- Kiali, Jaeger, and Prometheus integration commands for mesh observability
Frequently Asked Questions
What is a VirtualService in Istio?
A VirtualService defines traffic routing rules for a service within the mesh. It lets you split traffic by URI prefix, HTTP headers, weights, or other criteria and route to specific destination subsets. Without a VirtualService, Istio uses default round-robin routing.
What is the difference between PeerAuthentication and AuthorizationPolicy?
PeerAuthentication controls whether mutual TLS is required between services (encryption and identity). AuthorizationPolicy controls which service identities or external clients are allowed to call which operations (authorization). Both are often used together to secure service-to-service communication.
How does fault injection work in Istio?
Fault injection is configured inside a VirtualService using the fault field. You can inject an artificial delay (e.g., 5-second delay on 10% of requests) or an HTTP abort (e.g., 503 response on 5% of requests) to test how downstream services handle failures without modifying application code.
What does a DestinationRule do?
A DestinationRule defines policies applied to traffic after routing occurs. Common uses include configuring connection pool sizes, outlier detection (circuit breaking), load-balancing algorithms, and TLS settings for the destination service.
What is a ServiceEntry and when should I use it?
ServiceEntry registers an external service (outside the mesh) in the Istio service registry so traffic to it can be managed. Use it when your pods need to call external APIs or databases and you want to apply Istio traffic policies, retries, or timeouts to those calls.
How do Retry policies work in Istio?
Retry policies are defined in VirtualService under the retries field. You specify the number of attempts, a per-attempt timeout, and the conditions to retry on (e.g., 5xx errors, connection failures). Istio handles retries transparently without any changes to the application.
What is the Sidecar resource used for?
The Sidecar resource limits the set of services that a sidecar proxy knows about, reducing memory usage and configuration push latency in large meshes. By default a sidecar learns the full mesh topology; a Sidecar resource restricts its egress hosts to only what the workload actually needs.
How do I use EnvoyFilter?
EnvoyFilter provides direct access to the underlying Envoy proxy configuration using patch operations. It is an escape hatch for advanced scenarios not covered by higher-level Istio APIs, such as setting custom connect timeouts, adding custom Lua filters, or modifying cluster configuration.