mirror of https://github.com/istio/istio.io.git
traffic management doc improvements (#80)
* request timeout task * traffic management docs improvements * address review comments
This commit is contained in:
Frank Budinsky
GitHub
parent
8f628b0edd
commit
85bd965c56
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
@ -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](...).
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue