traffic management doc improvements (#80)

* request timeout task

* traffic management docs improvements

* address review comments
This commit is contained in:
Frank Budinsky 2017-04-28 15:12:12 -04:00 committed by GitHub
parent 8f628b0edd
commit 85bd965c56
7 changed files with 254 additions and 47 deletions

View File

@ -33,3 +33,5 @@ injected: delays and aborts. Delays are timing failures, mimicking
increased network latency, or an overloaded upstream service. Aborts are
crash failures that mimick failures in upstream services. Aborts usually
manifest in the form of HTTP error codes, or TCP connection failures.
Refer to [Istio's traffic management rules](./rules-configuration.html) for more details.

View File

@ -21,7 +21,7 @@ include:
instance in the load balancing pool
These features can be dynamically configured at runtime through
[Istio's traffic management rules](../tasks/timeouts-retries-circuit-breakers.html).
[Istio's traffic management rules](./rules-configuration.html).
The jitter between retries minimizes the impact of retries on an overloaded
upstream service, while timeout budgets ensure that the calling service
@ -41,9 +41,14 @@ and prevent localized failures from cascading instability to other nodes.
Istio's traffic management rules allow
operators to set global defaults for failure recovery per
service/version. However, consumers of a service can override these
defaults by providing
[request-level overrides through special HTTP headers](../tasks/timeouts-retries-circuit-breakers.html).
service/version. However, consumers of a service can also override
[timeout](/docs/reference/api/proxy-config.html#istio.proxy.v1alpha.config.HTTPTimeout.SimpleTimeoutPolicy)
and
[retry](/docs/reference/api/proxy-config.html#istio.proxy.v1alpha.config.HTTPRetry.SimpleRetryPolicy)
defaults by providing request-level overrides through special HTTP headers.
With the Envoy proxy implmentation, the headers are "x-envoy-upstream-rq-timeout-ms" and
"x-envoy-max-retries", respectively.
## FAQ

View File

@ -33,7 +33,7 @@ before beginning a canary deployment.
Decoupling traffic flow from infrastructure scaling allows Istio to provide
a variety of traffic management features that reside outside the
application code. Features include dynamic
[request routing](../tasks/request-routing.html) for A/B testing, canary releases,
[request routing](./request-routing.html) for A/B testing, canary releases,
gradual rollouts, etc., [failure recovery](./handling-failures.html)
using timeouts, retries, circuit breakers, and finally
[fault injection](./fault-injection.html) to test compatibility of

View File

@ -1,5 +1,5 @@
---
title: Service Model
title: Request Routing
overview: Describes how services are modeled within the Istio mesh, the notion of multiple versions of a service, and the communication model between services.
order: 20

View File

@ -16,7 +16,7 @@ services 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. See routing rules reference for detailed information. _link TBD_
etc. See [routing rules reference](/docs/reference/api/proxy-config.html) for detailed information.
For example, a simple rule to send 100% of incoming traffic for a "reviews"
service to version "v1" can be described using the Rules DSL as
@ -35,9 +35,9 @@ 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. Rules can be configured using the
[istioctl CLI](../reference/istioctl.html). See
[configuring request routing](../tasks/request-routing.html) section for
more information and examples.
[istioctl CLI](/docs/reference/istioctl.html). See the
[configuring request routing task](/docs/tasks/request-routing.html) for
examples.
There are two types of rules in Istio, **Routes** and **Destination
Policies** (these are not the same as Mixer policies). Both types of rules
@ -148,6 +148,99 @@ route:
weight: 75
```
### Timeouts and Retries
By default, the timeout for http requests is 15 seconds,
but this can be overridden in a route rule as follows:
```yaml
destination: "ratings.default.svc.cluster.local"
route:
- tags:
version: v1
httpReqTimeout:
simpleTimeout:
timeoutSeconds: 10
```
The number of retries for a given http request can also be specified in a route rule.
The maximum number of attempts, or as many as possible within the default or overriden timeout period,
can be set as follows:
```yaml
destination: "ratings.default.svc.cluster.local"
route:
- tags:
version: v1
httpReqRetries:
simpleRetry:
attempts: 3
```
Note that request timeouts and retries can also be
[overridden on a per-request basis](https://istio.io/docs/concepts/traffic-management/handling-failures.html#fine-tuning).
See the [request timeouts task](/docs/tasks/request-timeouts.html) for a demonstration of timeout control.
### Injecting faults in the request path
A route rule can specify one or more faults to inject
while forwarding http requests to the rule's corresponding request destination.
The faults can be either delays or aborts.
The following example will introduce a 5 second delay in 10% of the requests to the "v1" version of the "reviews" microservice.
```yaml
destination: reviews.default.svc.cluster.local
route:
- tags:
version: v1
httpFault:
delay:
percent: 10
fixedDelaySeconds: 5
```
The other kind of fault, abort, can be used to prematurely terminate a request,
for example, to simulate a failure.
The following example will return an HTTP 400 error code for 10%
of the requests to the "ratings" service "v1".
```yaml
destination: "ratings.default.svc.cluster.local"
route:
- tags:
version: v1
httpFault:
abort:
percent: 10
httpStatus: 400
```
Sometimes delays and abort faults are used together. For example, the following rule will delay
by 5 seconds all requests from the "reviews" service "v2" to the "ratings" service "v1" and
then abort 10 percent of them:
```yaml
destination: ratings.default.svc.cluster.local
match:
source: reviews.default.svc.cluster.local
sourceTags:
version: v2
route:
- tags:
version: v1
httpFault:
delay:
fixedDelaySeconds: 5
abort:
percent: 10
httpStatus: 400
```
To see fault injection in action, see the [fault injection task](/docs/tasks/fault-injection.html).
### Rules have precedence
Multiple route rules could be applied to the same destination. The order of
@ -232,6 +325,25 @@ tags:
loadBalancing: RANDOM
```
### Circuit Breakers
A simple circuit breaker can be set based on a number of criteria such as connection and request limits.
For example, the following destination policy
sets a limit of 100 connections to "reviews" service version "v1" backends.
```yaml
destination: reviews.default.svc.cluster.local
tags:
version: v1
circuitBreaker:
simpleCb:
maxConnections: 100
```
The complete set of simple circuit breaker fields can be found
[here](/docs/reference/api/proxy-config.html#istio.proxy.v1alpha.config.CircuitBreaker.SimpleCircuitBreakerPolicy).
### Destination Policy evaluation
Similar to route rules, destination policies are associated with a

View File

@ -0,0 +1,125 @@
---
title: Request Timeouts
overview: This task shows you how to setup request timeouts in Envoy using Istio.
order: 40
bodyclass: docs
layout: docs
type: markdown
---
This task shows you how to setup request timeouts in Envoy using Istio.
## Before you begin
* Setup Istio by following the instructions in the
[Installation guide](/docs/tasks/installing-istio.html).
* Deploy the [bookinfo](/docs/samples/bookinfo.html) sample application.
* Initialize the application version routing by running the following command:
```bash
$ istioctl create -f route-rule-all-v1.yaml
```
## Request timeouts
A timeout for http requests can be specified using the *httpReqTimeout* field of a routing rule.
By default, the timeout is 15 seconds, but in this task we'll override the `reviews` service
timeout to 1 second.
To see its effect, however, we'll also introduce an artificial 2 second delay in calls
to the `ratings` service.
1. Route requests to v2 of the `reviews` service, i.e., a version that calls the `ratings` service
```bash
$ cat <<EOF | istioctl replace
type: route-rule
name: reviews-default
spec:
destination: reviews.default.svc.cluster.local
route:
- tags:
version: v2
EOF
```
1. Add a 2 second delay to calls to the `ratings` service:
```bash
$ cat <<EOF | istioctl replace
type: route-rule
name: ratings-default
spec:
destination: ratings.default.svc.cluster.local
route:
- tags:
version: v1
httpFault:
delay:
percent: 100
fixedDelaySeconds: 2.0
EOF
```
1. Open the Bookinfo URL (http://$GATEWAY_URL/productpage) in your browser
You should see the bookinfo application working normally (with ratings stars displayed),
but there is a 2 second delay whenever you refresh the page.
1. Now add a 1 second request timeout for calls to the `reviews` service
```bash
$ cat <<EOF | istioctl replace
type: route-rule
name: reviews-default
spec:
destination: reviews.default.svc.cluster.local
route:
- tags:
version: v2
httpReqTimeout:
simpleTimeout:
timeoutSeconds: 1.0
EOF
```
1. Refresh the Bookinfo web page
You should now see that it returns in 1 second (instead of 2), but the reviews are unavailable.
## Understanding what happened
In this task, we used Istio to set the request timeout for calls to the `reviews`
microservice to 1 second (instead of the default 15 seconds).
Since the `reviews` service subsequently calls the `ratings` service when handling requests,
we used Istio to inject a 2 second delay in call to `ratings`, so that we would cause the
`reviews` service to take longer than 1 second to complete and consequently we coud see the
timeout in action.
We observed that the Bookinfo productpage (which calls the `reviews` service to populate the page),
instead of displaying reviews, displayed
the message: Sorry, product reviews are currently unavailable for this book.
This was the result of it recieving the timeout error from the `reviews` service.
If you check out the [fault injection task](./fault-injection.html), you'll find out that the `productpage`
microservice also has its own application-level timeout (3 seconds) for calls to the `reviews` microservice.
Notice that in this task we used an Istio route rule to set the timeout to 1 second.
Had we instead set the timeout to something greater than 3 seconds (e.g., 4 seconds) the timeout
would have had no effect since the more restrictive of the two will take precedence.
More details can be found [here](/docs/concepts/traffic-management/handling-failures.html#faq).
One more thing to note about timeouts in Istio is that in addition to overriding them in route rules,
as we did in this task, they can also be overridden on a per-request basis if the application adds
an "x-envoy-upstream-rq-timeout-ms" header on outbound requests. In the header
the timeout is specified in millisecond (instead of second) units.
## What's next
* Learn more about [failure handling](/docs/concepts/traffic-management/handling-failures.html).
* Learn more about [routing rules](/docs/concepts/traffic-management/rules-configuration.html).

View File

@ -1,37 +0,0 @@
---
title: Timeouts, Retries, and Circuit Breakers
overview: This task shows you how to setup timeouts, retries, and circuit breakers in Envoy using Istio.
order: 40
bodyclass: docs
layout: docs
type: markdown
---
This task shows you how to setup timeouts, retries, and circuit breakers in
Envoy using Istio.
## Before you begin
* Do this.
* Do this too.
## Doing ...
1. Do this.
1. Do this next. Possibly read this [related explanation](...).
## Understanding ...
Here's an interesting thing to know about the steps you just did.
## What's next
* Learn more about [this](...).
* See this [related task](...).