Traffic management with Istio in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this Istio VirtualService configuration?

Given this VirtualService YAML snippet, what will be the percentage of traffic routed to version v2 of the service?

Kubernetes

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

A 20%

B 80%

C 50%

D 0%

💡 Hint

Look at the weights assigned to each subset in the route section.

The VirtualService routes 80% of traffic to subset v1 and 20% to subset v2, so v2 gets 20%.

🧠 Conceptual

intermediate

Which Istio resource controls the routing rules for traffic splitting?

In Istio, which resource is responsible for defining how traffic is split between different versions of a service?

A DestinationRule

B Gateway

C ServiceEntry

D VirtualService

💡 Hint

This resource defines HTTP routing rules and traffic distribution.

VirtualService defines routing rules including traffic splitting between subsets.

❓ Troubleshoot

advanced

Why does traffic not split as expected despite correct VirtualService weights?

You configured a VirtualService to split traffic 50-50 between v1 and v2 subsets. However, all traffic goes to v1. What is the most likely cause?

A DestinationRule does not define subsets v1 and v2

B Gateway resource is missing

C ServiceEntry is blocking traffic to v2

D Sidecar proxy is not installed

💡 Hint

Check if subsets used in VirtualService are defined elsewhere.

If subsets are not defined in DestinationRule, traffic routing to those subsets fails, defaulting to one version.

🔀 Workflow

advanced

Order the steps to implement canary deployment with Istio traffic shifting

Arrange these steps in the correct order to perform a canary deployment using Istio traffic management.

A 1,3,2,4

B 1,2,3,4

C 2,1,3,4

D 2,3,1,4

💡 Hint

Think about deploying first, then defining subsets, then routing, then shifting traffic.

First deploy v2, then define subsets in DestinationRule, then create VirtualService for routing, then increase traffic gradually.

✅ Best Practice

expert

What is the best practice to avoid downtime during Istio traffic shifting?

When shifting traffic between service versions in Istio, what practice helps avoid downtime and errors?

A Disable sidecar proxies during deployment

B Delete old version before shifting traffic

C Use gradual traffic shifting with monitoring and rollback

D Shift 100% traffic immediately to new version

💡 Hint

Think about minimizing risk and detecting issues early.

Gradual traffic shifting with monitoring allows detecting problems early and rolling back if needed, avoiding downtime.

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