> ## 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. # Demo Destination Rules > Demo of Istio DestinationRule and VirtualService showing subset definitions and weighted traffic splits with configuration examples, commands, and tips for traffic policies and routing 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 ` 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: ```bash theme={null} # 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: ```bash theme={null} 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): ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} kubectl exec -ti -n test test -- /bin/bash ``` Inside the test pod, verify the service responds on port 5000 at `/hello`: ```bash theme={null} 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`): ```bash theme={null} 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`: ```yaml theme={null} 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: ```bash theme={null} 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`: ```yaml theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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`: ```yaml theme={null} # Update the 'weight' fields in vs.yaml route entries # weight: 95 for subset v1 # weight: 5 for subset v2 ``` Apply the modified VirtualService: ```bash theme={null} kubectl apply -f vs.yaml ``` Test again from the client pod: ```bash theme={null} 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 case | Description | Example snippet | | --------------------------------- | ------------------------------------------- | ---------------------------------- | | Load balancer | Change LB algorithm for a host | See "Load balancer policy" below | | Connection pool / circuit breaker | Limit connections, tune timeouts | See "Connection pool" below | | Subset-specific policy | Apply different policies per subset | See "Subset-specific policy" below | | Outlier detection | Evict unhealthy endpoints automatically | See "Outlier detection" below | | TLS client settings | Configure mTLS or TLS settings for outbound | See "TLS settings" below | Below are example DestinationRule YAMLs you can reuse. Load balancer policy (LEAST\_REQUEST): ```yaml theme={null} 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): ```yaml theme={null} 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: ```yaml theme={null} 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): ```yaml theme={null} 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): ```yaml theme={null} 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. ## Links and references * Istio Traffic Management: [https://istio.io/latest/docs/tasks/traffic-management/](https://istio.io/latest/docs/tasks/traffic-management/) * VirtualService reference: [https://istio.io/latest/docs/reference/config/networking/virtual-service/](https://istio.io/latest/docs/reference/config/networking/virtual-service/) * DestinationRule reference: [https://istio.io/latest/docs/reference/config/networking/destination-rule/](https://istio.io/latest/docs/reference/config/networking/destination-rule/) * Kubernetes basics: [https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) This concludes the DestinationRule demo. Try creating DestinationRules and VirtualServices in a lab environment and experiment with different traffic-splitting and policy combinations.