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.