istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fixing broken links

This commit is contained in:
Shriram Rajagopalan 2017-04-24 13:25:23 -04:00
parent d066320f26
commit c3ae3612e3
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
_docs/concepts/rules-configuration.md
View File

@ -132,7 +132,7 @@ Each backend corresponds to a specific version of the destination service,
where versions can be expressed using _tags_.
If there are multiple registered instances with the specified tag(s),
they will be routed to based on the [load balancing policy](#loadBalancing) configured for the service,
they will be routed to based on the load balancing policy configured for the service,
or round-robin by default.
For example, the following rule will route 25% of traffic for the "reviews" service to instances with

2
_docs/concepts/service-model.md
View File

@ -24,7 +24,7 @@ way to subdivide service instances by versions (`v1`, `v2`) or environment
versions: they could be iterative changes to the same service, deployed in
different environments (prod, staging, dev, etc.). Common scenarios where
this occurs include A/B testing, canary rollouts, etc. Istio's [traffic
management rules - TBD]() can refer to the service versions, to provide
management rules](./rules-configuration.html) can refer to the service versions, to provide
additional control over traffic between services.
## Communication between services

6
_docs/concepts/traffic-management-overview.md
View File

@ -30,9 +30,9 @@ 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](./request-routing.html) for A/B testing, canary releases,
gradual rollouts, etc., [failure recovery (TBD)](./handling-failures.html)
[request routing](../tasks/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 (TBD)](./fault-injection.html) to test compatibility of
[fault injection](./fault-injection.html) to test compatibility of
failure recovery policies across services. These capabilities are realized
through the Envoy sidecars/proxies deployed across the service mesh.