<commit_before>---
bodyclass: docs
headline: 'Routing & Traffic Management'
layout: docs
title: Routing & Traffic Management
type: markdown
sidenav: doc-side-reference-nav.html
---

## Overview

Istio provides a simple Domain-specific language (DSL) based on the proto3
schema (documented
[here](https://github.com/istio/api/blob/master/proxy/v1/config/cfg.md)) to
control how API calls and layer-4 traffic flows across various
microservices in the application deployment. The DSL allows the operator to
configure service level properties such as circuit breakers, timeouts,
retries, as well as set up common continuous deployment tasks such as
canary rollouts, A/B testing, staged rollouts with %-based traffic splits,
etc.

For example, a simple rule to send 100% of incoming traffic for a "reviews" microservice
to version "v1" can be described using the Rules DSL as follows:

```yaml
destination: reviews.default.svc.cluster.local
route:
- tags:
    version: v1
  weight: 100
```

The destination is the name of the service (specified as a fully qualified
domain name (FQDN)) to which the traffic is being routed. In a Kubernetes
deployment of Istio, the route *tag*
"version: v1" corresponds to a Kubernetes *label* "version: v1".  The rule
ensures that only Kubernetes pods containing the label "version: v1"
will receive traffic.
<commit_msg>reference YAML to protobuf mapping doc<commit_after>---
bodyclass: docs
headline: 'Routing & Traffic Management'
layout: docs
title: Routing & Traffic Management
type: markdown
sidenav: doc-side-reference-nav.html
---

## Overview

Istio provides a simple Domain-specific language (DSL) to
control how API calls and layer-4 traffic flows across various
microservices in the application deployment. The DSL is a
[YAML mapping](../concepts/writing-config.md) of a
[protobuf](https://developers.google.com/protocol-buffers/docs/proto3)
schema documented [here](https://github.com/istio/api/blob/master/proxy/v1/config/cfg.md).
The DSL allows the operator to
configure service level properties such as circuit breakers, timeouts,
retries, as well as set up common continuous deployment tasks such as
canary rollouts, A/B testing, staged rollouts with %-based traffic splits,
etc.

For example, a simple rule to send 100% of incoming traffic for a "reviews" microservice
to version "v1" can be described using the Rules DSL as follows:

```yaml
destination: reviews.default.svc.cluster.local
route:
- tags:
    version: v1
  weight: 100
```

The destination is the name of the service (specified as a fully qualified
domain name (FQDN)) to which the traffic is being routed. In a Kubernetes
deployment of Istio, the route *tag*
"version: v1" corresponds to a Kubernetes *label* "version: v1".  The rule
ensures that only Kubernetes pods containing the label "version: v1"
will receive traffic.

{'fraction_non_alphanumeric': 0.08030996829869673, 'fraction_numerical': 0.009862627685804861, 'mean_word_length': 4.795918367346939, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 3, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6313399', 'n_tokens_mistral': 834, 'n_tokens_neox': 782, 'n_words': 366}