Demo Request Timeouts Retries

In this lesson you’ll learn how to configure request timeouts and retries using Istio VirtualService resources. We’ll deploy the sample httpbin application and a simple test pod, then demonstrate how to enforce timeouts and retries and observe their effect via requests and proxy logs.

Prepare the cluster and deploy httpbin

Confirm your current namespace (showing labels is optional):

kubectl get ns --show-labels

Deploy httpbin and create a test pod with curl installed (image: curlimages/curl):

kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/httpbin/httpbin.yaml
kubectl run test --image=curlimages/curl --restart=Never --command -- sleep 1d

Verify pods are running:

kubectl get pods

Example output (trimmed):

NAME                         READY   STATUS      RESTARTS   AGE
httpbin-787cdcc9df-xx9gd     2/2     Running     0          1m
test                         1/1     Running     0          30s

Confirm the httpbin service exists:

kubectl get svc

Example output:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
httpbin      ClusterIP   10.108.160.240  <none>        8000/TCP   1m
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    10m

From the test pod, verify a basic request works:

kubectl exec -ti test -- curl --head http://httpbin:8000

You should see a 200 OK response header.

Implementing a request timeout

Create a VirtualService that enforces a 2 second timeout for HTTP requests to the httpbin service. vs-timeout.yaml:

apiVersion: networking.istio.io/v1
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:

kubectl apply -f vs-timeout.yaml
kubectl get virtualservice

Test the behavior using httpbin’s delay endpoint:

A 1 second delay is within the 2s timeout and should succeed:

kubectl exec -ti test -- curl http://httpbin:8000/delay/1

Example JSON response:

{
  "args": {},
  "headers": {
    "Host": "httpbin:8000",
    "User-Agent": ["curl/7.88.1"],
    "X-Envoy-Attempt-Count": ["1"]
  },
  "method": "GET",
  "origin": "127.0.0.1:4017",
  "url": "http://httpbin:8000/delay/1"
}

A 2 second delay equals the configured timeout and will be terminated by the proxy:

kubectl exec -ti test -- curl http://httpbin:8000/delay/2

Typical result:

upstream request timeout

Explanation: the VirtualService timeout causes the Envoy proxy to abort the request if the upstream service does not respond within the configured period (2s). Increase the timeout if you expect longer upstream processing (for example, try timeout: 5s and /delay/3 to confirm).

Implementing retries

First, remove the timeout VirtualService:

kubectl delete -f vs-timeout.yaml

Create a VirtualService that enables retries: vs-retries.yaml:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin-vs
spec:
  hosts:
    - httpbin
  http:
    - route:
        - destination:
            host: httpbin
            port:
              number: 8000
      retries:
        attempts: 3
        perTryTimeout: 1s
        retryOn: 5xx

Apply the new VirtualService:

kubectl apply -f vs-retries.yaml

What this configuration means:

attempts: number of retry attempts (3)
perTryTimeout: timeout for each individual attempt (1s)
retryOn: which error classes trigger retries (here 5xx server errors)

Test retries using httpbin’s status endpoint

httpbin exposes /status/<code> to return arbitrary HTTP status codes.

Confirm a normal GET works:

kubectl exec -ti test -- curl --head http://httpbin:8000/get

You should see HTTP/1.1 200 OK.

Generate a 500 and observe the response and proxy behavior:

kubectl exec -ti test -- curl --head http://httpbin:8000/status/500

You will receive HTTP/1.1 500 Internal Server Error as the final response to the client.

To observe retries, tail the httpbin pod’s proxy logs (the istio-proxy container). First get the httpbin pod name and then tail logs:

kubectl get pods -l app=httpbin
kubectl logs -f <httpbin-pod-name> -c istio-proxy
# Example:
kubectl logs -f httpbin-787cdcc9df-xx9gd -c istio-proxy

Look for repeated GET /status/500 log entries — these show the proxy making retry attempts. Example (trimmed) log excerpt:

[2025-04-15T17:21:14.709Z] "GET /status/500 HTTP/1.1" 500 - via_upstream "-" 0 1 0 "-" "curl/7.88.1" ...
[2025-04-15T17:21:14.726Z] "GET /status/500 HTTP/1.1" 500 - via_upstream "-" 0 1 0 "-" "curl/7.88.1" ...
[2025-04-15T17:21:14.732Z] "GET /status/500 HTTP/1.1" 500 - via_upstream "-" 0 1 0 "-" "curl/7.88.1" ...

Those repeated lines indicate the proxy retried the request according to the VirtualService configuration. The client receives the final non-success status (500) unless one of the retries succeeds.

Key fields reference (VirtualService HTTP route)

Field	Purpose	Example
`timeout`	Maximum total duration for the request before Envoy aborts	`2s`
`retries.attempts`	Number of retry attempts proxy should make	`3`
`retries.perTryTimeout`	Timeout for each retry attempt	`1s`
`retries.retryOn`	Which error classes trigger retries (e.g., `5xx`, `gateway-error`)	`5xx`
`route.destination`	Upstream service and port	`host: httpbin`, `port.number: 8000`

Notes and tips

Timeouts and retries are configured on the VirtualService HTTP route. Use timeouts to bound request latency, and use retries to handle transient 5xx errors — but be careful: retries increase load on upstreams. Tune attempts and perTryTimeout according to your application behavior.

Common guidance:

Apply a sensible per-request timeout so clients don’t wait indefinitely.
Use limited retries and short perTryTimeout values to recover from brief upstream failures without causing excessive upstream load.
Monitor proxy logs and application metrics to tune the values for your workload.

Example reference snippets

VirtualService with a timeout:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin-vs
spec:
  hosts:
    - httpbin
  http:
    - timeout: 2s
      route:
        - destination:
            host: httpbin
            port:
              number: 8000

VirtualService with retries:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin-vs
spec:
  hosts:
    - httpbin
  http:
    - route:
        - destination:
            host: httpbin
            port:
              number: 8000
      retries:
        attempts: 3
        perTryTimeout: 1s
        retryOn: 5xx

Links and References

That wraps up this lesson on configuring timeouts and retries with Istio VirtualServices.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Demo Request Timeouts Retries

Prepare the cluster and deploy httpbin

Implementing a request timeout

Implementing retries

Test retries using httpbin’s status endpoint

Key fields reference (VirtualService HTTP route)

Notes and tips

Example reference snippets

Links and References

Watch Video

Practice Lab

​Prepare the cluster and deploy httpbin

​Implementing a request timeout

​Implementing retries

​Test retries using httpbin’s status endpoint

​Key fields reference (VirtualService HTTP route)

​Notes and tips

​Example reference snippets

​Links and References

Watch Video

Practice Lab

Prepare the cluster and deploy httpbin

Implementing a request timeout

Implementing retries

Test retries using httpbin’s status endpoint

Key fields reference (VirtualService HTTP route)

Notes and tips

Example reference snippets

Links and References