Skip to main content

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.

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:

​
1. Verify namespace and sidecar injection

Confirm your namespaces and labels (to check sidecar injection status if your cluster uses automatic injection): 
# Show namespaces with labels
kubectl get ns --show-labels
Example welcome message you may see in a lab environment: 
# 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: 
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: 
kubectl run test --image=curlimages/curl --restart=Never --command -- sleep 3600
Verify pods are running: 
kubectl get pods
Example output: 
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: 
kubectl get svc
Example output (angle-bracketed values are shown literally inside the code block): 
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
httpbin       ClusterIP   10.108.160.240   <none>        8000/TCP    25s
kubernetes    ClusterIP   10.96.0.1        <none>        443/TCP     4m15s
From the test pod, curl the /get endpoint to verify basic connectivity: 
kubectl exec -ti test -- curl http://httpbin:8000/get
Sample JSON response (abridged): 
{
  "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: 
# 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: 
kubectl apply -f vs-timeout.yaml
kubectl get virtualservice
Example output: 
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):
# 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):
# 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: 
# 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: 
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: 
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: 
kubectl get pods -l app=httpbin
View the Istio sidecar logs (replace httpbin-pod with the actual pod name): 
kubectl logs `echo <httpbin-pod>` -c istio-proxy
Or follow logs live while making requests: 
kubectl logs -f `echo <httpbin-pod>` -c istio-proxy
(If you prefer standard placeholder usage inside interactive shells, use: kubectl logs <httpbin-pod> -c istio-proxy and replace <httpbin-pod> 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

FieldPurposeExample
timeoutMaximum lifetime for an individual request on a route2s
retries.attemptsNumber of retry attempts for a route3
retries.perTryTimeoutTimeout for each retry attempt2s
retries.retryOnConditions 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:

Watch Video

Practice Lab