Destination Rules

DestinationRules are as important as VirtualServices in Istio traffic management. A VirtualService intercepts client traffic destined for a service and applies routing policies (like path/host matching and traffic splitting) to direct that traffic to a target service. DestinationRules complement VirtualServices by defining policies that apply after routing — once traffic arrives at the destination service. In practice, DestinationRules let you map logical subset names to specific pod labels and attach traffic policies (load balancing, connection pools, circuit breaking, TLS, etc.) to those subsets. Use case example: to split traffic 50/50 between two versions of a workload, define subsets in a DestinationRule and reference those subsets from a VirtualService. The VirtualService performs the routing and weight assignment; the DestinationRule binds subset names to pod labels and configures endpoint-level behaviors.

How DestinationRules and VirtualServices work together

VirtualService: decides how traffic is routed (hosts, path/URI matches, weights, headers).
DestinationRule: applies policies to the concrete destination after routing (per-subset or host-level settings).
Subsets: logical names in a DestinationRule that map to pods via label selectors. VirtualServices reference these subset names to route to specific workload versions.

Example: two deployments (v1 & v2), one Service, DestinationRule with subsets, and VirtualService traffic split

Deployments for v1 and v2 (each with 3 replicas):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment-v1
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
      version: v1
  template:
    metadata:
      labels:
        app: frontend
        version: v1
    spec:
      containers:
        - name: app
          image: app:1.1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment-v2
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
      version: v2
  template:
    metadata:
      labels:
        app: frontend
        version: v2
    spec:
      containers:
        - name: app
          image: app:2.1

A single Kubernetes Service selects both versions via the shared app: frontend label:

apiVersion: v1
kind: Service
metadata:
  name: app-svc
  namespace: frontend
spec:
  ports:
    - port: 80
      name: http
  selector:
    app: frontend

DestinationRule that defines subsets (v1 and v2) by matching pod labels:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: app-ds
  namespace: frontend
spec:
  host: app-svc
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

VirtualService that references those subsets and splits traffic 50/50:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app-vs
  namespace: frontend
spec:
  hosts:
    - app-svc
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: app-svc
            port:
              number: 80
            subset: v1
          weight: 50
        - destination:
            host: app-svc
            port:
              number: 80
            subset: v2
          weight: 50

Resource summary

Resource Type	Purpose	Example
Deployment	Define workload versions (pods/labels)	`app-deployment-v1`, `app-deployment-v2`
Service	Single logical service that fronts multiple versions	`app-svc`
DestinationRule	Map subset names to pod labels, apply policies	`app-ds`
VirtualService	Route and split traffic to subsets	`app-vs`

Key points

DestinationRules are applied after routing decisions are made by VirtualServices.
Subsets are logical names in a DestinationRule that map to pods via labels; VirtualServices reference these subset names to direct traffic.
DestinationRules control per-subset or host-level policies:
- Load balancing algorithms
- Connection pool sizes
- Timeouts and retries
- Circuit breaking
- Client TLS / mTLS settings
Create DestinationRules in the same namespace as the targeted workloads. The host in the DestinationRule can be the short service name (e.g., app-svc) or the full FQDN (e.g., app-svc.frontend.svc.cluster.local).
Ensure subset names used in VirtualServices exactly match the subset names defined in DestinationRules.

Ensure the subset names used in the VirtualService match the subset names defined in the DestinationRule, and place the DestinationRule in the same namespace as the service/workloads it targets.

DestinationRules enable resilience and fine-grained control of service-to-service traffic — for example, configuring connection pool sizes, timeouts, retries, circuit breaking, and TLS. See the Istio docs for the full set of options. References:

The image displays documentation for "Destination Rules Options" in a structured format, detailing elements like "DestinationRule," "LoadBalancerSettings," and various fields with descriptions related to network configuration.

Now, let’s proceed to a demo and go over these concepts in practice.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

How DestinationRules and VirtualServices work together

Example: two deployments (v1 & v2), one Service, DestinationRule with subsets, and VirtualService traffic split

Resource summary

Key points

Watch Video

​How DestinationRules and VirtualServices work together

​Example: two deployments (v1 & v2), one Service, DestinationRule with subsets, and VirtualService traffic split

​Resource summary

​Key points

Watch Video

How DestinationRules and VirtualServices work together

Example: two deployments (v1 & v2), one Service, DestinationRule with subsets, and VirtualService traffic split

Resource summary

Key points