Configure Istio Traffic Management for Production

This skill provides production-ready Istio traffic management templates for a service mesh: four core resources (VirtualService for host-based routing, DestinationRule for service-based policies, Gateway for cluster-edge ingress/egress, ServiceEntry for external services), flowing as Client -> Gateway -> VirtualService -> DestinationRule -> Service, plus seven ready-to-adapt YAML templates.

Use it when configuring service-to-service routing, implementing canary or blue-green deployments, setting up circuit breakers and retries, configuring load balancing, mirroring traffic for testing, or injecting faults for chaos engineering. Open resources/implementation-playbook.md for detailed examples beyond what's here, and skip this skill for anything outside Istio traffic management.

The seven templates: (1) basic routing - a header-matched VirtualService (routing a specific user to subset v2, everyone else to v1) paired with a DestinationRule defining v1/v2/v3 subsets by label; (2) canary deployment - a weighted 90/10 stable/canary split, with a DestinationRule connection pool (100 max TCP connections, HTTP/2 upgrade, 100 max pending requests, 1000 max HTTP/2 requests); (3) circuit breaker - a DestinationRule with connection-pool limits (max connections, pending/HTTP2 requests, max retries) plus outlier detection (eject after 5 consecutive 5xx errors, 30s interval/base ejection time, up to 50% ejection, 30% minimum healthy); (4) retry and timeout - a 10s timeout with 3 retry attempts, 3s per-try timeout, and a specific retryOn condition list; (5) traffic mirroring - mirroring 100% of v1 traffic to v2 for shadow testing; (6) fault injection - a 10% chance of a 5s fixed delay and a 5% chance of aborting with a 503; and (7) an ingress Gateway (HTTPS on port 443 with a TLS secret, wildcard host) paired with a path-prefixed VirtualService routing /api/v1 to a backend service.

Load balancing strategies: simple algorithms (ROUND_ROBIN, LEAST_CONN, RANDOM, PASSTHROUGH) or consistent-hash sticky sessions keyed on an HTTP header (e.g. x-user-id), cookie, source IP, or query parameter. Named best practices: start simple and add complexity incrementally, use subsets to version services clearly, always set reasonable timeouts, enable retries with backoff and limits, and monitor with Kiali and Jaeger - while avoiding over-retrying (cascading failures), skipping outlier detection/circuit breakers, mirroring to production instead of test environments, and skipping canary testing with a small traffic percentage first. Debugging commands:

istioctl analyze
istioctl proxy-config routes deploy/my-app -o json
istioctl proxy-config endpoints deploy/my-app
istioctl proxy-config log deploy/my-app --level debug

Platform and SRE teams configuring production Istio traffic management - routing, canary/blue-green rollout, circuit breaking, retries, mirroring, and fault injection - who need ready-made templates and debugging commands rather than writing each resource from scratch.