Traffic management with Istio in Kubernetes - Mini Project: Build & Apply

Traffic management with Istio

📖 Scenario: You are working as a DevOps engineer managing microservices in a Kubernetes cluster. Your team uses Istio to control traffic flow between services. You need to set up a simple traffic routing rule to split traffic between two versions of a service.

🎯 Goal: Learn how to create an Istio VirtualService resource to route 80% of traffic to version v1 of a service and 20% to version v2.

📋 What You'll Learn

Create a Kubernetes YAML manifest for an Istio VirtualService

Define routing rules with weighted traffic split

Apply the manifest to the cluster

Verify the routing configuration

💡 Why This Matters

🌍 Real World

Istio traffic management is used in microservices environments to control how requests are routed between different versions of services. This helps with gradual rollouts, A/B testing, and canary deployments.

💼 Career

DevOps engineers and SREs use Istio to manage service traffic safely and efficiently in Kubernetes clusters, improving deployment strategies and system reliability.

1

Create the base VirtualService YAML

Create a YAML manifest named virtualservice.yaml with a VirtualService resource for the host myservice.example.com. Include the apiVersion as networking.istio.io/v1beta1 and kind as VirtualService. Add metadata with name: myservice. Define an empty spec section for now.

Kubernetes

# Your code here

Hint

Start with the basic structure of an Istio VirtualService YAML manifest.

2

Add hosts and HTTP route placeholders

In the spec section of virtualservice.yaml, add a hosts list containing myservice.example.com. Then add an empty http list to prepare for routing rules.

Kubernetes

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myservice
spec: 
  # Add hosts and http keys below
  # Your code here

Hint

The hosts field is a list of service hostnames. The http field will hold routing rules.

3

Define weighted routing rules for versions v1 and v2

Inside the http list, add one item with a route list. Define two destinations: one with host: myservice.example.com and subset: v1 with weight: 80, and another with host: myservice.example.com and subset: v2 with weight: 20.

Kubernetes

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myservice
spec:
  hosts:
  - myservice.example.com
  http:
  # Add routing rules with weighted destinations below
  # Your code here

Hint

Use the route key with a list of destination entries, each specifying host, subset, and weight.

4

Apply the VirtualService and verify routing

Run the command kubectl apply -f virtualservice.yaml to apply the routing rules. Then run kubectl get virtualservice myservice -o yaml to display the applied configuration.

Kubernetes

# Your code here

Hint

Use kubectl apply to update the cluster and kubectl get to verify the resource.

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