Learn Istio - Core Traffic Management (VirtualService & DestinationRule)

#Introduction

All workloads are in the mesh now. Time for the most interesting part: controlling traffic. Episode 5 covers the two CRDs you will write most often — VirtualService and DestinationRule — and how to use them for routing, traffic splitting, redirects, and even protection against failures.

Master these two resources well: almost every traffic management pattern in the following episodes (resilience, canary, gateway) stands on top of VirtualService and DestinationRule.

#Routing Primitives in VirtualService

#host, match, and route

A VirtualService defines how traffic heading to a host is directed. The basic structure: hosts names the destination service, match selects requests based on conditions (URI, header, method), and route determines the final destination:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-routing
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: /api/v1
    route:
    - destination:
        host: reviews
        subset: v1
  - route:
    - destination:
        host: reviews
        subset: v2

Rule order matters: the first matching rule is executed. Requests with the /api/v1 prefix go to subset v1, and everything else (the second rule, which has no match) goes to v2. match with uri.prefix is just one of many conditions — there are also uri.exact, uri.regex, headers, and method.

#Weight, Redirect, and Rewrite

Weights split traffic without conditions:

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

The weight: 90 and weight: 10 split sends 90 percent of traffic to v1 and 10 percent to v2 — the most basic canary pattern.

For redirects, the http block uses redirect.uri, which tells the client about a new location; for rewrites, rewrite.uri replaces the path before it is forwarded to the destination service. Both can be combined with match, for example replacing the /migrasi prefix with /api/baru before reaching the reviews service.

#DestinationRule: Destination Policies

#Subsets

A subset is a logical division of a service, usually based on version labels:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Without subsets, a VirtualService can only direct traffic to the entire service's Pods. With the v1 and v2 subsets, routing becomes very precise. The selection rule uses the same labels as kubectl get pods -l version=v1.

#Connection Pool and Outlier Detection

The connection pool manages the connection capacity to upstreams, while outlier detection removes unhealthy endpoints from the pool. Both live in the trafficPolicy of a DestinationRule:

spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 5s
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 1m
      maxEjectionPercent: 50

maxConnections: 100 protects the backend from excessive connections, while consecutive5xxErrors: 5 temporarily ejects a Pod after 5 5xx errors — this is the foundation of the Envoy circuit breaker, which we will use more aggressively in episode 7.

#Practical Examples: A/B and Traffic Splitting

#A/B Based on Headers

For A/B testing, header-based routing fits better than weights:

spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        x-group:
          exact: eksperimen
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Requests with the x-group: eksperimen header go to v2, everything else to v1. A/B testing like this does not change application code at all.

#Verifying Routing Results

Look at the configuration the sidecar received and test with curl:

kubectl get virtualservice reviews-routing -o yaml
istioctl proxy-config route deploy/reviews-v1 | grep reviews
kubectl exec deploy/reviews-v1 -c istio-proxy -- curl -s http://reviews:9080/

istioctl proxy-config route deploy/reviews-v1 shows the routes actually applied in Envoy — the bridge between Istio YAML and the real configuration.

#Summary

Episode 5 unlocked the power of Istio traffic management: VirtualService for match-based routing, weights, redirects, and rewrites; DestinationRule for subsets, connection pools, outlier detection, and load balancing; plus A/B and traffic splitting patterns you can use right away.

Key takeaways:

• VirtualService manages traffic direction; DestinationRule manages destination behavior.
• match is processed in order: the first rule that matches is executed.
• Weights split traffic; header matching suits A/B testing.
• Subsets require consistent labels in your Deployments.
• The connection pool protects the backend from excessive connections.
• Outlier detection is the foundation of the Envoy circuit breaker.
• istioctl proxy-config route verifies the real configuration in Envoy.

In the next episode, episode 6, we will leave the cluster: gateways, ingress, and egress — distinguishing the ingress gateway from egress, TLS termination and SNI-based routing, HTTP to HTTPS redirects, and ServiceEntry for external services.