Practise vocabulary for service mesh traffic management: virtual services, destination rules, canary deployments, circuit breakers, retry policies, and timeout configuration.
0 / 5 completed
1 / 5
In Istio, what is a VirtualService and what does it control?
A VirtualService configures the Envoy sidecar proxies to route requests according to rules. Example: route 90% of traffic to version v1 and 10% to version v2 (canary). Route requests with header 'x-canary: true' to v2 regardless of weight. Apply a 3-second timeout and 2 retries. The VirtualService is the traffic routing policy; the DestinationRule configures what happens when traffic reaches each destination.
2 / 5
What is a DestinationRule in Istio traffic management?
DestinationRule configures traffic behaviour after the VirtualService has determined the destination. Key capabilities: defining subsets (e.g., 'v1' = pods with label version:v1, 'v2' = pods with label version:v2) for VirtualService routing. Load balancing policy: ROUND_ROBIN, LEAST_CONN, RANDOM. Connection pool: max connections, pending requests, retries. Outlier detection (circuit breaker): eject pods that return 5xx errors consecutively.
3 / 5
What is 'traffic splitting' via service mesh and how does it enable canary deployments?
Mesh-based canary deployment: VirtualService weight: [{destination: {host: myservice, subset: v1}, weight: 95}, {destination: {host: myservice, subset: v2}, weight: 5}]. This sends 5% of real production traffic to v2 regardless of replica count — unlike Kubernetes replica-based canary, which requires maintaining proportional pod counts. Mesh canary allows 1% traffic to v2 with 0 replicas waste and enables header-based routing for internal testing.
4 / 5
What is a 'circuit breaker' in service mesh vocabulary and when does it activate?
Circuit breaker in Istio is implemented as outlier detection in DestinationRule: consecutiveGatewayErrors: 5 means after 5 consecutive 5xx responses, the pod is ejected from the load balancing pool for baseEjectionTime (e.g., 30 seconds). This prevents a single failing pod from receiving traffic while it recovers. The circuit breaker 'opens' (ejects) and then 'half-opens' after the ejection time to probe if the pod has recovered.
5 / 5
What is a 'retry policy' in service mesh traffic management vocabulary?
VirtualService retry configuration: retries: {attempts: 3, perTryTimeout: 2s, retryOn: 'gateway-error,connect-failure,retriable-4xx'}. The mesh retries automatically, transparently to the application — the app makes one call, the sidecar handles up to 3 attempts internally. Key consideration: only retry idempotent operations. The retryOn field specifies conditions: gateway-error (502/503/504), connect-failure (connection refused), retriable-4xx (409 Conflict).