> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Request Timeouts Retries > Demo showing how to configure per-route timeouts and retries in an Istio VirtualService using httpbin, curl, kubectl, and observing istio-proxy sidecar logs In this demo we'll configure per-route request timeouts and retries in an Istio VirtualService. We'll deploy the httpbin sample application, create a test pod with `curl`, and demonstrate timeout and retry behavior using httpbin's diagnostic endpoints. * Target audience: anyone learning Istio traffic management (VirtualService). * Tools used: `kubectl`, `curl`, and Istio sidecar logs. References: * Istio VirtualService: [https://istio.io/latest/docs/reference/config/networking/virtual-service/](https://istio.io/latest/docs/reference/config/networking/virtual-service/) * httpbin: [https://httpbin.org](https://httpbin.org) ## 1. Verify namespace and sidecar injection Confirm your namespaces and labels (to check sidecar injection status if your cluster uses automatic injection): ```bash theme={null} # Show namespaces with labels kubectl get ns --show-labels ``` Example welcome message you may see in a lab environment: ```bash theme={null} # Example lab prompt Welcome to the KodeKloud Hands-On lab All rights reserved root@controlplane ~ ➜ ``` For this demo we'll use the `default` namespace. ## 2. Deploy httpbin and create a test pod (with curl) Deploy the httpbin sample application: ```bash theme={null} kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/httpbin/httpbin.yaml ``` Create a test pod that includes `curl` and stays running so you can exec into it: ```bash theme={null} kubectl run test --image=curlimages/curl --restart=Never --command -- sleep 3600 ``` Verify pods are running: ```bash theme={null} kubectl get pods ``` Example output: ```bash theme={null} NAME READY STATUS RESTARTS AGE httpbin-787cdcc9df-xx9gd 2/2 Running 0 14s test 1/1 Running 0 30s ``` ## 3. Verify the httpbin service and basic request List services: ```bash theme={null} kubectl get svc ``` Example output (angle-bracketed values are shown literally inside the code block): ```bash theme={null} NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpbin ClusterIP 10.108.160.240 8000/TCP 25s kubernetes ClusterIP 10.96.0.1 443/TCP 4m15s ``` From the test pod, curl the `/get` endpoint to verify basic connectivity: ```bash theme={null} kubectl exec -ti test -- curl http://httpbin:8000/get ``` Sample JSON response (abridged): ```json theme={null} { "args": {}, "headers": { "Host": ["httpbin:8000"], "X-Envoy-Attempt-Count": ["1"] }, "method": "GET", "url": "http://httpbin:8000/get" } ``` ## 4. Implement a per-route timeout (VirtualService) Create a VirtualService that sets a 2-second timeout for HTTP requests to the `httpbin` service. Save this as `vs-timeout.yaml`: ```yaml theme={null} # vs-timeout.yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: httpbin-vs spec: hosts: - httpbin http: - timeout: 2s route: - destination: host: httpbin port: number: 8000 ``` Apply the VirtualService and confirm it exists: ```bash theme={null} kubectl apply -f vs-timeout.yaml kubectl get virtualservice ``` Example output: ```bash theme={null} NAME GATEWAYS HOSTS AGE httpbin-vs ["httpbin"] 3s ``` ### Test the timeout with httpbin's /delay endpoint httpbin exposes `/delay/{n}` which delays the response by `n` seconds. Use it to test the configured timeout. * This request should succeed (delay less than timeout): ```bash theme={null} # Delay of 1 second — should succeed with 2s timeout kubectl exec -ti test -- curl -i http://httpbin:8000/delay/1 ``` * This request should fail (delay equal to or greater than timeout): ```bash theme={null} # Delay of 2 seconds — will hit the 2s timeout and fail kubectl exec -ti test -- curl -i http://httpbin:8000/delay/2 ``` If the backend does not respond within the configured `timeout` (2s), Istio will terminate the request and return an error instead of waiting for the delayed response. Timeouts are configured per HTTP route in the VirtualService. Choose a timeout that fits expected backend latencies and the client experience you want to provide. ## 5. Implement retries You can either modify the existing VirtualService or create a new one to enable retries. The example below configures up to 3 retry attempts for `5xx` errors, with a 2s `perTryTimeout`. Save this as `vs-retries.yaml`: ```yaml theme={null} # vs-retries.yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: httpbin-retries spec: hosts: - httpbin http: - retries: attempts: 3 perTryTimeout: 2s retryOn: "5xx" route: - destination: host: httpbin port: number: 8000 ``` Apply it: ```bash theme={null} kubectl apply -f vs-retries.yaml kubectl get virtualservice ``` ### Test retries using httpbin's /status endpoint httpbin exposes `/status/{code}` which returns the requested HTTP status code. Trigger a 500 to cause retries: ```bash theme={null} kubectl exec -ti test -- curl -i http://httpbin:8000/status/500 ``` When the route receives a 5xx error, Istio will retry according to the VirtualService `retries` configuration (in this example: `attempts: 3`). Retry attempts are visible in the sidecar proxy logs. ### Inspect istio-proxy logs to observe retries Get the httpbin pod name: ```bash theme={null} kubectl get pods -l app=httpbin ``` View the Istio sidecar logs (replace `httpbin-pod` with the actual pod name): ```bash theme={null} kubectl logs `echo ` -c istio-proxy ``` Or follow logs live while making requests: ```bash theme={null} kubectl logs -f `echo ` -c istio-proxy ``` (If you prefer standard placeholder usage inside interactive shells, use: `kubectl logs -c istio-proxy` and replace `` with the pod name.) In the logs you will observe the initial failing request and subsequent retry attempts issued by the proxy. Retries are specified per HTTP route using `retries.attempts`, `retries.perTryTimeout`, and `retries.retryOn`. Be cautious: retries can increase load on already failing backends. ## 6. Key VirtualService timeout & retry fields | Field | Purpose | Example | | ----------------------- | -------------------------------------------------------------- | ------- | | `timeout` | Maximum lifetime for an individual request on a route | `2s` | | `retries.attempts` | Number of retry attempts for a route | `3` | | `retries.perTryTimeout` | Timeout for each retry attempt | `2s` | | `retries.retryOn` | Conditions that trigger retries (e.g., `5xx`, `gateway-error`) | `"5xx"` | ## 7. Summary * Configure `timeout` and `retries` in an Istio VirtualService to control how requests are timed out and retried. * Use httpbin's `/delay/{n}` to validate timeout behavior and `/status/{code}` to validate retries. * Inspect the `istio-proxy` sidecar logs to observe timeout terminations and retry attempts. Links and references: * [Istio VirtualService docs](https://istio.io/latest/docs/reference/config/networking/virtual-service/) * [httpbin — HTTP Request & Response Service](https://httpbin.org) * [Kubernetes Documentation](https://kubernetes.io/docs/)