One of the top features of Backyards is the ability to fully configure how traffic flows in the service mesh. This kind of routing works in the application layer, and lets you configure sophisticated rules based on URIs, ports or headers.
In Istio, routing is mostly described in Virtual Services, and then translated to Envoy configuration. Backyards covers almost everything that could be described with Virtual Services, but comes with an easy to understand structure of request matches, routes and different actions.
You can add routing or redirect rules for requests that match certain criteria, and configure different rules like retry policies, request timeouts, or fault injection.
Try it out! 🔗︎
Using the Backyards CLI 🔗︎
These examples work out of the box with the demo application packaged with Backyards. Change the service name and namespace to match your service.
To see the current routing rules for a particular service, use the route get command:
backyards routing route get backyards-demo/movies
Settings for backyards-demo/movies
Matches Routes Redirect Timeout Retry Rewrite Mirror To
any 33% movies:8080 (v1) - - - - -
33% movies:8080 (v2)
34% movies:8080 (v3)
To create, or edit an existing routing rule, use route set.
Let’s start with a simple example, that routes all incoming traffic to the payments service to the payments destination.
Backyards automatically creates the corresponding Istio virtual service and destination rule.
The any keyword after the match switch means matching all requests.
It cannot be omitted, because unlike Istio, we wanted to make it explicit.
backyards routing route set backyards-demo/payments -m any -d payments -w 100
Now let’s add a few other actions to the same rule.
Note that you don’t have to specify the destination or the weight again. The CLI merges the rules for a specific match:
backyards routing route set backyards-demo/payments -m any --timeout 4s --retry-attempts 2 --retry-per-try-timeout 2s
Finally try a routing rule with an advanced matching configuration, and set a different timeout and retry policy.
When you specify multiple --match arguments, there will be OR relations between them.
The rule will match requests that match the first, or the second rule.
Inside a match, you can specify multiple rules that have an AND relation.
This is how you can match requests against a specific URL and an HTTP method for example.
backyards routing route set backyards-demo/payments --match "uri=/version" --match "uri=/api/v1,method=GET" -d payments -w 100 --timeout 3s --retry-attempts 3 --retry-per-try-timeout 2s
Let’s see how our matching rules look like now.
Rules are evaluated in top-down order.
Note how the any rule is always the last one to help avoiding rule shadowing.
For other matching rules, it is the user’s responsibility to handle the order of rules.
Ordering is not yet supported in Backyards.
backyards routing route get backyards-demo/payments
Settings for backyards-demo/payments
Matches Routes Redirect Timeout Retry Rewrite Mirror To
(uri=/version) OR (uri=/api/v1 AND method=GET) 100% payments - 3s 3x (2s ptt) - -
any 100% payments - 4s 2x (2s ptt) - -
To delete the rules, use these commands:
backyards routing route delete backyards-demo/payments --match "uri=/version" --match uri=/api/v1,method=GET --non-interactive
backyards routing route delete backyards-demo/payments --match any --non-interactive
Tip 1: all CLI commands and switches have short names, check the CLI docs to get to know them.
Tip 2: the CLI has an interactive mode: try the above commands with
--match anyas the only argument
Using the Backyards UI 🔗︎
Routing can also be configured from the dashboard.
The routing form can help you easily set up complex routing rules, that otherwise would be pretty hard to figure out.
Select the service on the Services or the Topology view, and create a new rule on the traffic management tab.
You can also edit or delete rules, and you can also view the full YAML description of the virtual service.
