Traffic management with Istio in Kubernetes - Commands & Configuration

Introduction

Managing how user requests flow between services can be tricky. Istio helps control this traffic smoothly, letting you split, route, and test service versions without changing your app code.

When you want to gradually roll out a new version of a service to a small percentage of users before full release

When you need to route traffic to different service versions based on user location or device type

When you want to test a new service version with real traffic without affecting all users

When you want to quickly switch traffic back to a stable version if a new release has issues

When you want to control traffic flow for canary deployments or A/B testing

Config File - virtual-service.yaml

virtual-service.yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90
    - destination:
        host: my-app
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

This file defines two Istio resources:

• VirtualService: Controls how traffic is split between service versions. Here, 90% goes to version v1 and 10% to v2.
• DestinationRule: Defines subsets of the service based on labels, so Istio knows which pods belong to v1 or v2.

Commands

Apply the Istio VirtualService and DestinationRule to control traffic routing between service versions.

Terminal

kubectl apply -f virtual-service.yaml

Expected Output

virtualservice.networking.istio.io/my-app created

destinationrule.networking.istio.io/my-app created

Verify that the VirtualService resource is created and check its configuration.

Terminal

kubectl get virtualservice my-app -o yaml

Expected Output

apiVersion: networking.istio.io/v1beta1

kind: VirtualService

metadata:

  name: my-app

spec:

  hosts:

  - my-app

  http:

  - route:

    - destination:

        host: my-app

        subset: v1

      weight: 90

    - destination:

        host: my-app

        subset: v2

      weight: 10

→

-o yaml - Outputs the resource details in YAML format for easy reading

Check that pods with version v2 are running and ready to receive traffic.

Terminal

kubectl get pods -l app=my-app,version=v2

Expected Output

NAME                          READY   STATUS    RESTARTS   AGE

my-app-v2-5d8f7c7d6d-abc12    2/2     Running   0          10m

→

-l - Filters pods by label selectors

Check that Istio proxies have received the new traffic routing configuration.

Terminal

istioctl proxy-status

Expected Output

NAME                                                   CDS        LDS        EDS        RDS        PILOT

my-app-v1-7f9d8c7d8f-xyz12.default                     SYNCED     SYNCED     SYNCED     SYNCED     SYNCED

my-app-v2-5d8f7c7d6d-abc12.default                     SYNCED     SYNCED     SYNCED     SYNCED     SYNCED

Key Concept

If you remember nothing else from this pattern, remember: Istio VirtualService lets you control how much traffic goes to each version of your service without changing your app code.

Common Mistakes

Not defining subsets in DestinationRule when using VirtualService routing

Istio cannot identify service versions properly, so traffic routing fails or defaults to one version

Always define subsets in DestinationRule matching the labels used on your pods for each version

Applying VirtualService without verifying pods for all versions are running

Traffic may be routed to non-existent pods causing errors or downtime

Check pods with correct labels are running and ready before applying traffic routing

Forgetting to check Istio proxy status after applying config

Istio proxies may not have updated, so traffic routing changes won't take effect

Run 'istioctl proxy-status' to confirm proxies have synced the new config

Summary

Create a DestinationRule to define service subsets by version labels.

Create a VirtualService to split traffic between these subsets with weights.

Apply the configuration with kubectl and verify pods and proxy status.

Use Istio to control traffic flow without changing application code.

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