Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

DestinationRule resources in Istio define endpoint groups (subsets) and per-destination traffic policies (load balancing, connection pools, outlier detection, TLS, etc.). When paired with a VirtualService, DestinationRules enable advanced traffic routing scenarios such as weighted traffic splits between versions of an application.
Both the client and server namespaces must have Istio sidecar injection enabled for Istio routing to work across namespaces. Use istioctl analyze -n <namespace> to confirm.
This demo walks through a common scenario: splitting traffic between two versions of a HelloWorld service using a DestinationRule to define subsets and a VirtualService to split traffic by weight.

​
Prerequisites and quick checks

Run these commands to confirm cluster state and Istio injection: 
# List namespaces and labels (look for istio-injection=enabled)
kubectl get ns --show-labels

# Confirm Istio resources and analyze a namespace
istioctl analyze -n default
istioctl analyze -n test
If a namespace needs injection enabled: 
kubectl create ns test            # if not present
kubectl label namespace test istio-injection=enabled
Verify the HelloWorld sample is deployed in the default namespace and that pods have sidecars (Ready should be 2/2): 
kubectl get pods -n default --show-labels
kubectl get svc -n default --show-labels
Create a simple test client pod in the test namespace for curl-based tests: 
kubectl run -n test test --image=nginx --restart=Never --command -- sleep 1d
kubectl get pods -n test
Exec into the test pod for manual testing: 
kubectl exec -ti -n test test -- /bin/bash
Inside the test pod, verify the service responds on port 5000 at /hello: 
curl helloworld.default.svc:5000/hello
# Example responses:
# Hello version: v2, instance: helloworld-v2-...
# Hello version: v1, instance: helloworld-v1-...
Without a VirtualService, Kubernetes service load balancing determines which pod receives traffic. The following steps add a DestinationRule (to create subsets) and a VirtualService (to control traffic split).

​
1) Inspect labels used for subset selection

DestinationRule subsets target pods by labels. For this demo, confirm your pods have a version label (e.g., v1, v2): 
kubectl get pods -n default --show-labels
kubectl get svc -n default --show-labels
Typical labels you should see:
  • Service: app=helloworld,service=helloworld
  • Pods: app=helloworld,version=v1 and app=helloworld,version=v2
We will use version to create subsets in the DestinationRule.

​
2) Create the DestinationRule (define subsets)

A DestinationRule by itself defines subsets and policies but does not change traffic distribution. Save this as dr.yaml: 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: hello-world-ds
  namespace: default
spec:
  host: helloworld
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
Apply and verify: 
kubectl apply -f dr.yaml
kubectl get destinationrules.networking.istio.io -n default
# Example output:
# NAME            HOST        AGE
# hello-world-ds  helloworld  5s

​
3) Create the VirtualService (50/50 traffic split)

Now create a VirtualService to split HTTP traffic between the v1 and v2 subsets. Save as vs.yaml: 
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello-world-vs
  namespace: default
spec:
  hosts:
  - helloworld
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: helloworld.default.svc.cluster.local
        port:
          number: 5000
        subset: v1
      weight: 50
    - destination:
        host: helloworld.default.svc.cluster.local
        port:
          number: 5000
        subset: v2
      weight: 50
Apply and confirm: 
kubectl apply -f vs.yaml
kubectl get virtualservices.networking.istio.io -n default
# Example output:
# NAME             GATEWAYS   HOSTS            AGE
# hello-world-vs   []         ["helloworld"]   5s
Test from the test pod with multiple requests: 
kubectl exec -ti -n test test -- /bin/bash
# inside pod:
for i in {1..6}; do curl -sS helloworld.default.svc:5000/hello; echo; done
# Expect approximately half v1 and half v2 responses
Ensure the VirtualService destination port matches the application’s listening port (5000 in this demo). A mismatched port (for example, using 80) will prevent traffic from reaching the application.

​
4) Adjust traffic weights (example: 95/5)

To change the split, update the weight values in vs.yaml. Example: send 95% to v1 and 5% to v2: 
# Update the 'weight' fields in vs.yaml route entries
# weight: 95 for subset v1
# weight: 5  for subset v2
Apply the modified VirtualService: 
kubectl apply -f vs.yaml
Test again from the client pod: 
kubectl exec -ti -n test test -- /bin/bash
# inside pod:
for i in {1..20}; do curl -sS helloworld.default.svc:5000/hello; echo; done
# Expect mostly v1 responses (~95%) with occasional v2

​
5) DestinationRule capabilities — quick reference

DestinationRules are used to define subsets (by pod labels) and to apply traffic policies at the destination level. Common uses include:
  • Subsets for versioned deployments (A/B testing, canary)
  • Load balancing policies (ROUND_ROBIN, LEAST_REQUEST, etc.)
  • Connection pool tuning and circuit breaking (max connections, timeouts)
  • Outlier detection (eject unhealthy endpoints)
  • TLS client settings (SIMPLE, MUTUAL)
Use cases and examples:
Use caseDescriptionExample snippet
Load balancerChange LB algorithm for a hostSee “Load balancer policy” below
Connection pool / circuit breakerLimit connections, tune timeoutsSee “Connection pool” below
Subset-specific policyApply different policies per subsetSee “Subset-specific policy” below
Outlier detectionEvict unhealthy endpoints automaticallySee “Outlier detection” below
TLS client settingsConfigure mTLS or TLS settings for outboundSee “TLS settings” below
Below are example DestinationRule YAMLs you can reuse. Load balancer policy (LEAST_REQUEST): 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
Connection pool settings (tuning timeouts and max connections): 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: bookinfo-redis
spec:
  host: myredissrv.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms
        tcpKeepalive:
          time: 7200s
          interval: 75s
Subset-specific load balancing policy (ROUND_ROBIN) and an alternate subset: 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: testversion
    labels:
      version: v3
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
Outlier detection and HTTP/TCP limits (useful for circuit breaking): 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-cb-policy
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 7
      interval: 5m
      baseEjectionTime: 15m
TLS client settings (MUTUAL or SIMPLE): 
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: db-mtls
spec:
  host: mydbserver.prod.svc.cluster.local
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: tls-foo
spec:
  host: "*.foo.com"
  trafficPolicy:
    tls:
      mode: SIMPLE

​
6) Tips, pitfalls, and exam-style reminders

  • DestinationRules define endpoint subsets and policies; VirtualServices perform the routing between those subsets.
  • Always verify that the VirtualService destination host and port match the actual Service and application listening port.
  • Use istioctl analyze to detect common configuration mistakes.
  • For canary or percentage-based rollouts, use small increments and monitor with logs/metrics.
  • DestinationRules and VirtualServices are foundational for Istio traffic management and are commonly featured in labs and certification exam scenarios.
This concludes the DestinationRule demo. Try creating DestinationRules and VirtualServices in a lab environment and experiment with different traffic-splitting and policy combinations.

Watch Video

Practice Lab