Configure Istio Traffic Management for Production

This skill covers Istio traffic management for production service mesh deployments. It defines four core resources - VirtualService (routes traffic to destinations, host-based), DestinationRule (defines policies applied after routing, service-based), Gateway (configures ingress/egress at the cluster edge), and ServiceEntry (adds external services mesh-wide) - flowing as Client to Gateway to VirtualService (routing) to DestinationRule (policies) to Service (pods). It provides seven templates: basic header-matched routing to a versioned subset with a fallback route, a weighted canary deployment (90/10 split between stable and canary subsets with a connection-pool traffic policy), a circuit breaker using outlierDetection (ejecting hosts after 5 consecutive 5xx errors, 30s base ejection, max 50% ejection), retry and timeout configuration (a 10s timeout, 3 retry attempts with a 3s per-try timeout, retrying on specific conditions including 503 and connect-failure), traffic mirroring (mirroring 100% of v1 traffic to a v2 subset for testing), fault injection (injecting a 5s delay on 10% of requests and a 503 abort on 5%), and an ingress Gateway with TLS termination routed to a backend VirtualService by URI prefix. It also covers load-balancing strategies (ROUND_ROBIN, LEAST_CONN, RANDOM, PASSTHROUGH) and consistent-hash sticky sessions keyed by an HTTP header, cookie, source IP, or query parameter.

Use it for configuring service-to-service routing, implementing canary or blue-green deployments, setting up circuit breakers and retries, load balancing configuration, traffic mirroring for testing, or fault injection for chaos engineering. It does not apply outside Istio traffic management - a different domain or tool is out of scope. Its best-practices guidance recommends starting canary rollouts with a small traffic percentage and increasing gradually, setting realistic circuit breaker thresholds, testing fault injection in staging before production, monitoring metrics after every traffic change, and using istioctl analyze before applying configuration - and warns against routing 100% of traffic to an unverified new version, setting overly aggressive circuit breaker thresholds, forgetting to define a DestinationRule before referencing its subsets in a VirtualService, or skipping load testing before a major traffic shift.

Inputs: the service mesh's hosts, subsets/versions, and desired routing or resilience policy. Outputs: VirtualService, DestinationRule, Gateway, and ServiceEntry YAML manifests implementing the chosen routing, canary weighting, circuit breaking, retry/timeout, mirroring, or fault-injection behavior, plus debugging output from istioctl commands verifying the effective configuration.

Istio's networking.istio.io/v1beta1 API (VirtualService, DestinationRule, Gateway, ServiceEntry), istioctl for analysis and debugging (analyze, proxy-config routes, proxy-config endpoints, proxy-config log), and Kiali and Jaeger named for observability.

# Check VirtualService configuration
istioctl analyze

# View effective routes
istioctl proxy-config routes deploy/my-app -o json

# Check endpoint discovery
istioctl proxy-config endpoints deploy/my-app

# Debug traffic
istioctl proxy-config log deploy/my-app --level debug

Platform engineers running Istio in production who need correct VirtualService/DestinationRule configuration for canary rollouts, circuit breaking, retries, mirroring, or fault injection rather than trial-and-error YAML.