Istio Retries and Retry Amplification

Retries are set on the VirtualService route with `retries.attempts`, `retries.perTryTimeout`, and `retries.retryOn`. The `retryOn` field is the important one: it controls which failures get retried. Common values are `5xx`, `reset`, `connect-failure`, and `gateway-error`. Never put `retriable-4xx` on POST endpoints unless you know they're idempotent. The big danger is retry amplification in a deep call graph. If the gateway retries 3 times, and the next hop retries 3 times, and the hop after that retries 3 times, a single user request can produce 27 backend calls. When the downstream is already struggling, those retries are exactly what tips it from slow to dead. The fix is to retry only at the edge or only once at internal hops, and to set tight `perTryTimeout` so the total time is bounded. Pair retries with circuit breakers in the DestinationRule so once a host is failing, you stop hitting it instead of retrying into the fire. And make sure `attempts` plus `perTryTimeout` doesn't exceed the route's overall `timeout` — if it does, the timeout fires before retries finish and you waste budget.