mirror of https://github.com/istio/istio.io.git
fix links
This commit is contained in:
Shriram Rajagopalan
parent
cdc542b01d
commit
bb98028139
|
|
@ -9,7 +9,9 @@ type: markdown
|
|||
|
||||
The Istio service mesh consists of three major components:
|
||||
|
||||
- **Proxy**. The Istio proxy is designed to mediate inbound and outbound
|
||||
## Proxy
|
||||
|
||||
The Istio proxy is designed to mediate inbound and outbound
|
||||
traffic for all Istio-managed services. The Istio proxy is based on
|
||||
[Envoy](https://lyft.github.io/envoy/). Istio leverages Envoy's features
|
||||
such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC
|
||||
|
|
@ -19,24 +21,28 @@ Istio extends the proxy to interact with the mixer to enforce various
|
|||
access control policies rate limiting, ACLs, as well as telemetry
|
||||
reporting.
|
||||
|
||||
- **Mixer**. The Istio mixer is responsible for enforcing access control
|
||||
## Mixer
|
||||
|
||||
The Istio mixer is responsible for enforcing access control
|
||||
and usage policies across the service mesh and collects telemetry data from
|
||||
proxies and istio-managed services alike. The Istio proxy extracts request
|
||||
level attributes that are then evaluated by the mixer. More info on the
|
||||
attribute extraction and policy evaluation can be found
|
||||
[here](attributes.md). The mixer includes a flexible plugin model enabling
|
||||
[here](docs/reference/attributes.md). The mixer includes a flexible plugin model enabling
|
||||
it to interface to a variety of host environments and configured backends,
|
||||
abstracting the proxy and Istio-managed services from these details.
|
||||
|
||||
- **Manager**. The Istio manager serves as an interface between the user
|
||||
## Manager
|
||||
|
||||
The Istio manager serves as an interface between the user
|
||||
and Istio, collecting configuration, validating it and propagating it to
|
||||
various components. It abstracts platform-specific implementation details
|
||||
from the mixer and proxies, providing them with an
|
||||
[abstract representation](model.md) of user's services that is independent
|
||||
of the underlying platform. In addition, [traffic management rules](rule-dsl.md)
|
||||
of the underlying platform. In addition, [traffic management rules](docs/reference/rule-dsl.md)
|
||||
(i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules)
|
||||
can be programmed at runtime via the Istio Manager.
|
||||
|
||||
<img src="/img/arch.svg" alt="The overall architecture of an Istio-based service.">
|
||||
<img src="img/arch.svg" alt="The overall architecture of an Istio-based service.">
|
||||
|
||||
<div id="toc" class="toc mobile-toc"></div>
|
||||
|
|
|
|||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
bodyclass: docs
|
||||
headline: Architecture
|
||||
layout: docs
|
||||
sidenav: doc-side-guides-nav.html
|
||||
title: Architecture
|
||||
type: markdown
|
||||
---
|
||||
|
||||
The Istio service mesh consists of three major components:
|
||||
|
||||
- **Proxy**. The Istio proxy is designed to mediate inbound and outbound
|
||||
traffic for all Istio-managed services. The Istio proxy is based on
|
||||
[Envoy](https://lyft.github.io/envoy/). Istio leverages Envoy's features
|
||||
such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC
|
||||
proxying, circuit breakers, health checks, staged rollouts with %-based
|
||||
traffic split, fault injection, and a rich set of metrics. In addition,
|
||||
Istio extends the proxy to interact with the mixer to enforce various
|
||||
access control policies rate limiting, ACLs, as well as telemetry
|
||||
reporting.
|
||||
|
||||
- **Mixer**. The Istio mixer is responsible for enforcing access control
|
||||
and usage policies across the service mesh and collects telemetry data from
|
||||
proxies and istio-managed services alike. The Istio proxy extracts request
|
||||
level attributes that are then evaluated by the mixer. More info on the
|
||||
attribute extraction and policy evaluation can be found
|
||||
[here](attributes.md). The mixer includes a flexible plugin model enabling
|
||||
it to interface to a variety of host environments and configured backends,
|
||||
abstracting the proxy and Istio-managed services from these details.
|
||||
|
||||
- **Manager**. The Istio manager serves as an interface between the user
|
||||
and Istio, collecting configuration, validating it and propagating it to
|
||||
various components. It abstracts platform-specific implementation details
|
||||
from the mixer and proxies, providing them with an
|
||||
[abstract representation](model.md) of user's services that is independent
|
||||
of the underlying platform. In addition, [traffic management rules](rule-dsl.md)
|
||||
(i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules)
|
||||
can be programmed at runtime via the Istio Manager.
|
||||
|
||||
<img src="/img/arch.svg" alt="The overall architecture of an Istio-based service.">
|
||||
|
||||
<div id="toc" class="toc mobile-toc"></div>
|
||||
|
|
@ -18,13 +18,13 @@ different environments (different clouds & on-prem)
|
|||
|
||||
The mixer provides three core features:
|
||||
|
||||
- **Precondition Checking**. Enables callers to verify a number of preconditions before responding to an incoming request from a service consumer.
|
||||
**Precondition Checking**. Enables callers to verify a number of preconditions before responding to an incoming request from a service consumer.
|
||||
Preconditions can include whether the service consumer is properly authenticated, is on the service's whitelist, passes ACL checks, and more.
|
||||
|
||||
- **Telemetry Reporting**. Enables services to produce logging, monitoring, tracing and billing streams intended for the service producer itself as well as
|
||||
**Telemetry Reporting**. Enables services to produce logging, monitoring, tracing and billing streams intended for the service producer itself as well as
|
||||
for its consumers.
|
||||
|
||||
- **Quota Management**. Enables services to allocate and free quota on a number of dimensions, Quotas are used as a relatively simple resource management
|
||||
**Quota Management**. Enables services to allocate and free quota on a number of dimensions, Quotas are used as a relatively simple resource management
|
||||
tool to provide some fairness between service consumers when contending for limited resources.
|
||||
|
||||
## Mixer Adapters
|
||||
|
|
@ -34,6 +34,6 @@ to different backend systems that deliver core control-plane functionality, such
|
|||
enable the mixer to expose a single consistent control API, independent of the backends in use. The exact set of adapters
|
||||
used at runtime is determined through configuration.
|
||||
|
||||
<img src="/img/adapters.svg" alt="Mixer and its adapters.">
|
||||
<img src="img/adapters.svg" alt="Mixer and its adapters.">
|
||||
|
||||
<div id="toc" class="toc mobile-toc"></div>
|
||||
|
|
|
|||
|
|
@ -34,7 +34,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
|
||||
[routing rules](rule-dsl.md) can refer to the service versions, to provide
|
||||
[routing rules](docs/reference/rule-dsl.md) can refer to the service versions, to provide
|
||||
additional control over traffic between services.
|
||||
|
||||
**Tags** Each version of a service can be differentiated by a unique set of
|
||||
|
|
|
|||
Loading…
Reference in New Issue