Traffic management with Istio in Kubernetes - Step-by-Step Execution

Process Flow - Traffic management with Istio

Client sends request

↓

Istio Ingress Gateway receives

↓

Istio VirtualService evaluates rules

↓

Route to Service Version A

↓

Route to Service Version B

↓

Apply retries, timeouts

↓

Request forwarded to selected service

↓

Service responds

↓

Response sent back to client

The client request enters through Istio's gateway, where VirtualService rules decide routing, retries, and timeouts before forwarding to the appropriate service version.

Execution Sample

Kubernetes

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myservice
spec:
  hosts:
  - myservice.example.com
  http:
  - route:
    - destination:
        host: myservice
        subset: v1
      weight: 80
    - destination:
        host: myservice
        subset: v2
      weight: 20

This VirtualService routes 80% of traffic to version v1 and 20% to version v2 of 'myservice'.

Process Table

Step	Request Source	VirtualService Rule Evaluated	Routing Decision	Action Taken
1	Client sends request	Check host matches 'myservice.example.com'	Match	Proceed to HTTP route rules
2	Request matched	Evaluate HTTP route weights	80% to v1, 20% to v2	Route request accordingly
3	Request routed	Apply retries and timeout policies (if any)	No retries configured	Forward to selected service version
4	Service processes request	N/A	N/A	Service responds
5	Response sent	N/A	N/A	Response returned to client
6	Next request	Repeat steps 1-5	Based on traffic weights	Continuous traffic management

💡 Traffic routing completes after request is forwarded and response is returned.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Request Source	Client	Client	Client	Client
Routing Decision	None	80% v1, 20% v2	80% v1, 20% v2	80% v1, 20% v2
Action Taken	None	Route request	Forward request	Response returned

Key Moments - 3 Insights

Why does the VirtualService route 80% of traffic to v1 and 20% to v2?

Because the HTTP route weights specify 80 for v1 and 20 for v2, controlling traffic distribution as shown in execution_table step 2.

What happens if the host in the request does not match the VirtualService host?

The request will not match the VirtualService rules and will not be routed by Istio, as seen in execution_table step 1 where host matching is required.

Are retries or timeouts applied in this example?

No retries or timeouts are configured in this VirtualService, so none are applied during routing, as noted in execution_table step 3.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Istio decide how to split traffic between service versions?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Check the 'Routing Decision' column in execution_table step 2.

According to variable_tracker, what is the routing decision after step 3?

A No routing decision made

B 80% traffic to v1, 20% to v2

C 100% traffic to v1

D Traffic blocked

💡 Hint

Look at the 'Routing Decision' row under 'After Step 3' in variable_tracker.

If we add a retry policy, which step in the execution_table would change?

A Step 3

B Step 1

C Step 2

D Step 5

💡 Hint

Retries are applied during routing actions, see step 3 in execution_table.

Concept Snapshot

Istio Traffic Management:
- Use VirtualService to define routing rules
- Route traffic by host and HTTP rules
- Control traffic split with weights
- Apply retries and timeouts in routing
- Requests flow: Client -> Gateway -> VirtualService -> Service
- Responses return back through the same path

Full Transcript

Traffic management with Istio controls how client requests are routed to different versions of a service. The client sends a request to the Istio ingress gateway. Istio uses a VirtualService resource to match the request host and apply routing rules. These rules can split traffic between service versions by assigning weights, such as 80% to version v1 and 20% to version v2. Istio can also apply policies like retries and timeouts during routing. After routing, the request reaches the selected service version, which processes it and sends a response back to the client. This flow repeats for each request, enabling controlled and flexible traffic management.