Traffic management with Istio in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is Istio in the context of Kubernetes?

Istio is a service mesh that helps manage, secure, and observe traffic between microservices in Kubernetes clusters without changing application code.

beginner

What is a VirtualService in Istio?

A VirtualService defines how requests are routed to services within the mesh, allowing control over traffic routing rules like splitting, retries, and timeouts.

intermediate

How does Istio perform traffic splitting?

Istio splits traffic by defining weights in a VirtualService, sending a percentage of requests to different versions of a service for gradual rollouts or A/B testing.

intermediate

What is the purpose of DestinationRule in Istio?

DestinationRule configures policies for traffic to a service after routing, such as load balancing, connection pool settings, and circuit breakers.

advanced

How can Istio help with fault injection?

Istio can simulate failures like delays or aborts in service responses to test the resilience of applications using fault injection rules in VirtualService.

What Istio resource defines routing rules for directing traffic to different service versions?

A VirtualService

B DestinationRule

C Gateway

D ServiceEntry

VirtualService controls how requests are routed to different service versions.

Which Istio feature allows sending 20% of traffic to a new service version and 80% to the old one?

A Fault Injection

B Traffic Splitting

C Load Balancing

D Circuit Breaking

Traffic Splitting uses weights in VirtualService to divide traffic percentages.

What does a DestinationRule configure in Istio?

A Routing rules for incoming traffic

B Service discovery entries

C Policies like load balancing and connection pools for traffic after routing

D Ingress gateway settings

DestinationRule sets policies for traffic after routing, such as load balancing.

How does Istio help test application resilience?

A By injecting faults like delays or errors

B By automatically scaling pods

C By encrypting traffic

D By monitoring CPU usage

Istio can inject faults to simulate failures and test resilience.

Which Istio resource is used to expose services outside the mesh?

A Sidecar

B VirtualService

C DestinationRule

D Gateway

Gateway manages inbound and outbound traffic to/from the mesh.

Explain how Istio manages traffic routing between different versions of a service.

Think about how you can send some users to a new version while others stay on the old one.

Describe the role of DestinationRule in Istio traffic management.

It controls what happens after traffic is routed to a service.

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