Skip to content
advanced Phase 12 · Service Mesh

Traffic Management

Master traffic management with canary deployments, circuit breaking, and traffic splitting.

1h
0 problems
Topic Progress 0%

Canary and Progressive Delivery

Canary and Progressive Delivery

Kubernetes rolling updates move replicas, not traffic percentages. To send 5% of requests to a new version you need a mesh (or an ingress controller) that splits at L7:

http:
- route:
  - destination: { host: api, subset: stable }
    weight: 95
  - destination: { host: api, subset: canary }
    weight: 5

Progressive delivery wraps the split in gates: shift 5%, watch error rate and p99 against an SLO budget, advance to 50% then 100%, and snap weights back to 0 on breach (Flagger automates this loop against Prometheus). Blue/green is the simpler cousin: full cutover by flipping the Service selector, at double capacity cost.

Retries, Timeouts, Circuit Breaking

Retries, Timeouts, Circuit Breaking

A DestinationRule carries the resilience policy:

trafficPolicy:
  connectionPool:
    http: { http1MaxPendingRequests: 100, maxRequests: 10 }
  outlierDetection:
    consecutive5xxErrors: 5
    interval: 10s
    baseEjectionTime: 30s

VirtualService controls retry behavior:

http:
- retries:
    attempts: 3
    perTryTimeout: 2s
    retryOn: connect-failure,refused-stream,503
  timeout: 6s

Outlier detection ejects repeatedly failing hosts so the pool keeps serving from healthy ones; circuit breaking caps pending work so one slow dependency cannot exhaust client resources. Fault injection (abort with 503s, or fixed delays) rehearses client handling of exactly those failures before production sees them.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Retry storms. Retrying an overloaded service multiplies load by the attempt count — always bound attempts with a per-try timeout shorter than the overall deadline, and retry only idempotent calls.

Mesh + app double retries. If your code retries AND the proxy retries, attempts compound; pick one layer as the retry owner.

Ejection too aggressive. With 2 replicas, aggressive outlier detection can eject everyone and cause total blackout — size pools or relax thresholds.

Weights without gates. Static 90/10 forever is not a canary; without automated metric gates you will ship a bad release confidently.

Interview angle: lay out a canary plan with explicit percentages, the metrics you watch, the rollback trigger, and where retries live in your stack.

Quiz

1. Can a plain Kubernetes Deployment send 10% of traffic to a new version?

Question 1 options

2. What does outlierDetection do?

Question 2 options

3. Why keep perTryTimeout below the overall timeout?

Question 3 options

Flashcards

Question

Canary traffic split

Answer

Proxy-level weights (e.g. 95/5) between subsets, advanced by metric gates rather than by replica counts.

Question

Circuit breaker vs outlier detection

Answer

Breaker caps outstanding requests per cluster; outlier ejection removes individual failing hosts temporarily.

Question

retryOn conditions

Answer

Meshes retry selected conditions (connect-failure, refused-stream, 5xx) — restrict to idempotent traffic.

Question

Fault injection

Answer

Abort (status codes) or delay faults applied by the proxy to test client resilience under failure.

Revision Notes

Key Takeaways

  • 1. Traffic percentages live in the mesh; Deployments only manage replicas
  • 2. Bound retries with per-try and overall timeouts; avoid compounding retries across layers
  • 3. Outlier detection, connection pools, and fault injection are what keep cascades contained

Interview Tips

  • • Present a full canary: split percentages, the metrics and window you watch, and the rollback trigger
  • • Explain a retry storm mathematically (attempts × replicas × QPS) and how you bound it

Cheat Sheet

Canary = weighted routes (95/5 → gates → 100) + SLO checks. Policy: retries{attempts, perTryTimeout, retryOn} < overall timeout; outlierDetection consecutive5xx; fault injection to rehearse failures.

Continue Learning