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.

Practice

1. What is the primary purpose of an Istio VirtualService in traffic management?

easy

A. To define how requests are routed to different versions of a service

B. To store persistent data for services

C. To monitor CPU usage of pods

D. To create Kubernetes namespaces

Solution

1. Step 1: Understand VirtualService role

   An Istio VirtualService defines routing rules for directing traffic to services.

2. Step 2: Compare options

   Only To define how requests are routed to different versions of a service describes routing traffic to different service versions, which is the main use of VirtualService.

3. Final Answer:

   To define how requests are routed to different versions of a service -> Option A

4. Quick Check:

   VirtualService controls routing = A [OK]

Hint: VirtualService controls routing rules, not storage or monitoring [OK]

Common Mistakes:

• Confusing VirtualService with ConfigMap
• Thinking VirtualService manages resource usage
• Mixing VirtualService with namespace creation

2. Which of the following is the correct syntax to split 80% of traffic to version v1 and 20% to version v2 in an Istio VirtualService?

easy

A. weight: 80
version: v1
weight: 20
version: v2

B. route:
- destination:
host: myservice
subset: v1
weight: 80
- destination:
host: myservice
subset: v2
weight: 20

C. trafficSplit:
v1: 80
v2: 20

D. split:
v1: 0.8
v2: 0.2

Solution

1. Step 1: Recall Istio VirtualService traffic split syntax

   Traffic split uses route with destination and weight fields under each route.

2. Step 2: Match syntax to options

   route: - destination: host: myservice subset: v1 weight: 80 - destination: host: myservice subset: v2 weight: 20 correctly shows route list with destination.host, subset, and weight keys.

3. Final Answer:

   route: - destination: host: myservice subset: v1 weight: 80 - destination: host: myservice subset: v2 weight: 20 -> Option B

4. Quick Check:

   Correct route and weight syntax = D [OK]

Hint: Look for 'route' with destination and weight keys [OK]

Common Mistakes:

• Using invalid keys like 'trafficSplit' or 'split'
• Missing 'destination' block
• Incorrect indentation or missing dashes

3. Given this VirtualService snippet, what percentage of traffic goes to version v2?

route:
- destination:
    host: reviews
    subset: v1
  weight: 70
- destination:
    host: reviews
    subset: v2
  weight: 30

medium

A. 30%

B. 70%

C. 50%

D. 100%

Solution

1. Step 1: Identify weights for each version

   Version v1 has weight 70, v2 has weight 30.

2. Step 2: Calculate traffic percentage for v2

   Weight 30 means 30% of traffic is routed to v2.

3. Final Answer:

   30% -> Option A

4. Quick Check:

   Weight 30 means 30% traffic to v2 [OK]

Hint: Weight number equals traffic percentage [OK]

Common Mistakes:

• Confusing weights as cumulative
• Assuming equal split by default
• Ignoring subset field

4. You wrote this VirtualService snippet but traffic is not splitting as expected:

route:
- destination:
    host: productpage
    subset: v1
  weight: 50
- destination:
    host: productpage
    subset: v2
  weight: 60

What is the error?

medium

A. Subset names must be uppercase

B. Missing 'http:' key before 'route'

C. Host name should be the service IP, not name

D. Weights sum to more than 100, causing misrouting

Solution

1. Step 1: Check weights sum

   Weights are 50 and 60, totaling 110%, which is invalid.

2. Step 2: Understand traffic split rules

   Weights must sum to 100 or less to properly split traffic.

3. Final Answer:

   Weights sum to more than 100, causing misrouting -> Option D

4. Quick Check:

   Weights > 100 cause errors [OK]

Hint: Sum weights to 100 or less for valid splits [OK]

Common Mistakes:

• Ignoring total weight sum
• Forgetting 'http:' key is optional but recommended
• Thinking subset names are case sensitive

5. You want to route 100% of traffic from users with header version: v2 to version v2 of your service, and all others to v1. Which VirtualService configuration snippet achieves this?

hard

A. route:
- destination:
host: myservice
subset: v1
weight: 50
- destination:
host: myservice
subset: v2
weight: 50

B. route:
- destination:
host: myservice
subset: v2
weight: 100
headers:
request:
exact: {version: v2}
- destination:
host: myservice
subset: v1
weight: 100

C. http:
- match:
headers:
version:
exact: v2
route:
- destination:
host: myservice
subset: v2
- route:
- destination:
host: myservice
subset: v1

D. http:
- route:
- destination:
host: myservice
subset: v2
weight: 100

Solution

1. Step 1: Identify header-based routing syntax

   Istio uses http with match for header conditions.

2. Step 2: Check options for header match and routing

   http: - match: headers: version: exact: v2 route: - destination: host: myservice subset: v2 - route: - destination: host: myservice subset: v1 correctly matches header version: v2 and routes to subset v2, else routes to v1.

3. Final Answer:

   http: - match: headers: version: exact: v2 route: - destination: host: myservice subset: v2 - route: - destination: host: myservice subset: v1 -> Option C

4. Quick Check:

   Header match with http and route = A [OK]

Hint: Use 'http' with 'match' for header-based routing [OK]

Common Mistakes:

• Placing headers under route weight instead of match
• Splitting traffic by weight instead of header
• Omitting 'http:' block for routing rules