mirror of https://github.com/istio/istio.io.git
Revised overview (#205)
* Updated/restructured overview docs * Implement Martin's edits * Implement Martin's edits
This commit is contained in:
LisaFC
GitHub
parent
08391389b9
commit
c2b96efd07
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
title: Architecture
|
||||
overview: Highlights Istio's core architectural structure and components.
|
||||
|
||||
order: 30
|
||||
|
||||
layout: docs
|
||||
type: markdown
|
||||
---
|
||||
{% include home.html %}
|
||||
|
||||
This page presents an architectural overview for the Istio service mesh.
|
||||
|
||||
<img src="./img/architecture/arch.svg" title="The overall architecture of an Istio-based application." />
|
||||
|
||||
## The sidecar model
|
||||
|
||||
As monolithic applications are decomposed into a distributed system of microservices that scale dynamically, classic distributed system problems such as
|
||||
service discovery, load balancing, and failure recovery become increasingly import to solve uniformly. As the application gains more agility, it transitions
|
||||
towards a process wherein updates are made to different parts of the application at different times. Developers need the ability to experiment with
|
||||
different features in production, or deploy canary releases, without impacting the system as a whole. Operators need to enforce organization-wide policies,
|
||||
such as global rate limits, ACLs, etc., without requiring updates to each microservice.
|
||||
|
||||
Today, these problems are tackled piecemeal within the industry. Language-specific libraries, such as Ribbon/Hystrix from Netflix’s OSS stack, are used to
|
||||
satisfy basic necessities such as discovery, load balancing and circuit breaking. In a polyglot application, organizations need to maintain
|
||||
language-specific libraries for every language being used, dramatically increasing the maintenance cost.
|
||||
|
||||
A host of API management tools are typically bolted onto the edge of the infrastructure to provide subscription, metering, API metrics monitoring, rate
|
||||
limiting, etc. Continuous delivery and experimentation of new features in production is restricted to edge services using an edge proxy (e.g., Zuul/Nginx).
|
||||
Policy enforcement between mid-tier services is difficult or impossible as libraries provide little control over how traffic flows between microservices.
|
||||
|
||||
Compared to using language-specific libraries, the out-of-process transparent proxy approach has a much lower maintenance overhead. A single proxy
|
||||
implementation can be shared across all services in an organization. This single implementation can be optimized for performance while providing a variety
|
||||
of functions beneficial to all services in the application. It eliminates the need for applications to be rebuilt whenever new functionality is available.
|
||||
Support for continuous delivery, policy enforcement, and in-depth monitoring of service health can be engineered into the proxy and leveraged across
|
||||
different services (edge & middle-tier) with minimal effort on behalf of the application developer. As the proxy can act as both an edge proxy as well as a
|
||||
middle-tier router, middle-tier services can also take advantage of the continuous delivery and policy enforcement features provided. By offloading all
|
||||
aspects of communication, failure recovery, and policy enforcement to the proxy, the application logic is dramatically simplified.
|
||||
|
||||
## Envoy
|
||||
|
||||
Istio uses the Envoy proxy, a high-performance proxy developed in C++, to mediate all inbound and outbound traffic for all services in the service mesh.
|
||||
Istio leverages Envoy’s many built-in 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 rich metrics. In addition, Istio extends Envoy to interact with Mixer to
|
||||
enable policy enforcement and to report telemetry.
|
||||
|
||||
## Mixer
|
||||
|
||||
Mixer is responsible for enforcing access control and usage policies across the service mesh and collects telemetry data from the Envoy proxy and other
|
||||
services. The proxy extracts request level attributes which are sent to Mixer for evaluation. More information on the attribute extraction and policy
|
||||
evaluation can be found here. Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and
|
||||
infrastructure backends, abstracting
|
||||
the Envoy proxy and Istio-managed services from these details. More on Mixer [here]({{home}}/docs/concepts/policy-and-control/mixer.html).
|
||||
|
||||
## Istio-Manager
|
||||
|
||||
Istio-Manager serves as an interface between the user and Istio, collecting and validating configuration and propagating it to the various Istio components.
|
||||
It abstracts environment-specific implementation details from Mixer and Envoy, providing them with an abstract representation of the user’s services
|
||||
that is independent of the underlying platform. In addition, traffic management rules (i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules) can
|
||||
be programmed at runtime via Istio-Manager.
|
||||
|
||||
## Istio-Auth
|
||||
|
||||
Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management.
|
||||
It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce policy based
|
||||
on service identity rather than network controls. Future releases of Istio will add fine-grained access control and auditing to control
|
||||
and monitor who accesses your service, API, or resource, using a variety of access control mechanisms, including attribute and
|
||||
role-based access control as well as authorization hooks.
|
||||
|
||||
## What's next
|
||||
|
||||
* Read Istio's [overview](./overview.html).
|
||||
* Review Istio's [design goals](./goals.html).
|
||||
|
|
@ -8,7 +8,7 @@ layout: docs
|
|||
type: markdown
|
||||
---
|
||||
|
||||
This page the core principles that guide Istio's design.
|
||||
This page outlines the core principles that guide Istio's design.
|
||||
|
||||
Istio’s architecture is informed by a few key design goals that are essential to making the system capable of dealing with services at scale and with high
|
||||
performance.
|
||||
|
|
@ -36,8 +36,3 @@ The application of policy to API calls between services provides a great deal of
|
|||
policies to resources which are not necessarily expressed at the API level. For example applying quota to the amount of CPU consumed by a ML training task
|
||||
is more useful than applying quota to the call which initiated the work. To this end the policy system is maintained as a distinct service with its own API
|
||||
rather than being baked into the proxy/sidecar, allowing services to directly integrate with it as needed.
|
||||
|
||||
## What's next
|
||||
|
||||
* Read Istio's [overview](./overview.html).
|
||||
* Explore Istio's [high-level architecture](./architecture.html).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Overview
|
||||
overview: Provides a broad overview of what problems Istio is designed to solve.
|
||||
overview: Provides a conceptual introduction to Istio, including the problems it solves and its high-level architecture.
|
||||
|
||||
order: 15
|
||||
|
||||
|
|
@ -8,23 +8,27 @@ layout: docs
|
|||
type: markdown
|
||||
---
|
||||
|
||||
This page introduces Istio: an open platform to connect, manage, and secure microservices.
|
||||
This document introduces Istio: an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio's control plane functionality.
|
||||
|
||||
As monolithic applications transition towards a distributed microservice architecture they become more difficult to manage and understand. These
|
||||
architectures need basic necessities such as discovery, load balancing, failure recovery, metrics and monitoring, and more complex operational requirements
|
||||
such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication. The term service mesh is used to describe the network of
|
||||
microservices that make up applications and the interactions between them. As the service mesh grows in size and complexity, it becomes harder to understand
|
||||
and manage.
|
||||
Istio currently only supports service deployment on Kubernetes, though other environments will be supported in future versions.
|
||||
|
||||
Istio provides a complete solution to satisfy these diverse requirements of microservice applications, by providing developers and operators with
|
||||
behavioral insights and operational control over the service mesh as a whole. Istio does this by providing a number of key capabilities uniformly across the
|
||||
For detailed conceptual information about Istio components see our other [Concepts]({{home}}/docs/concepts/) guides.
|
||||
|
||||
## Why use Istio?
|
||||
|
||||
Istio addresses many of the challenges faced by developers and operators as monolithic applications transition towards a distributed microservice architecture. The term **service mesh** is often used to describe the network of
|
||||
microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand
|
||||
and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements
|
||||
such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.
|
||||
|
||||
Istio provides a complete solution to satisfy the diverse requirements of microservice applications by providing
|
||||
behavioral insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a
|
||||
network of services:
|
||||
|
||||
- **Traffic Management**. Control the flow of traffic and API calls between services, make calls more reliable and make the network more robust in the face
|
||||
- **Traffic Management**. Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face
|
||||
of adverse conditions.
|
||||
|
||||
- **Observability**. Gain understanding of the dependencies between services, the nature and flow of traffic between them and be able to quickly identify
|
||||
issues.
|
||||
- **Observability**. Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.
|
||||
|
||||
- **Policy Enforcement**. Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly
|
||||
distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.
|
||||
|
|
@ -40,17 +44,59 @@ initially focused on Kubernetes but are working to support other environments so
|
|||
- **Integration and Customization**. The policy enforcement component can be extended and customized to integrate with existing solutions for
|
||||
ACLs, logging, monitoring, quotas, auditing and more.
|
||||
|
||||
These capabilities greatly decrease the coupling between application code, the underlying platform and policy. This decreased coupling not only makes
|
||||
services easier to implement but also makes it simpler for operators to move application deployments between environments or to new policy schemes.
|
||||
These capabilities greatly decrease the coupling between application code, the underlying platform, and policy. This decreased coupling not only makes
|
||||
services easier to implement, but also makes it simpler for operators to move application deployments between environments or to new policy schemes.
|
||||
Applications become inherently more portable as a result.
|
||||
|
||||
Istio’s service mesh is logically split into a *data plane* and a *control plane*. The data plane is composed of a set of intelligent (HTTP, HTTP/2, gRPC, TCP or UDP)
|
||||
proxies deployed as sidecars that mediate and control all network communication between microservices. The control plane is responsible for managing and
|
||||
configuring proxies to route traffic, as well as enforce policies at runtime.
|
||||
## Architecture
|
||||
|
||||
An Istio service mesh is logically split into a **data plane** and a **control plane**.
|
||||
|
||||
- The **data plane** is composed of a set of intelligent
|
||||
proxies (Envoy) deployed as sidecars that mediate and control all network communication between microservices.
|
||||
- The **control plane** is responsible for managing and
|
||||
configuring proxies to route traffic, as well as enforcing policies at runtime.
|
||||
|
||||
The following diagram shows the different components that make up each plane:
|
||||
|
||||
<img src="./img/architecture/arch.svg" title="The overall architecture of an Istio-based application." />
|
||||
|
||||
### Envoy
|
||||
|
||||
Istio uses an extended version of the [Envoy](https://lyft.github.io/envoy/) proxy, a high-performance proxy developed in C++, to mediate all inbound and outbound traffic for all services in the service mesh.
|
||||
Istio leverages Envoy’s many built-in 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 rich metrics.
|
||||
|
||||
Envoy is deployed as a **sidecar** to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as [attributes]({{home}}/docs/concepts/policy-and-control/attributes.html), which in turn it can use in [Mixer]({{home}}/docs/concepts/policy-and-control/mixer.html) to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our [Design Goals]({{home}}/docs/concepts/goals.html).
|
||||
|
||||
### Mixer
|
||||
|
||||
[Mixer]({{home}}/docs/concepts/policy-and-control/mixer.html) is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other
|
||||
services. The proxy extracts request level [attributes]({{home}}/docs/concepts/policy-and-control/attributes.html), which are sent to Mixer for evaluation. More information on this attribute extraction and policy
|
||||
evaluation can be found in [Mixer Configuration]({{home}}/docs/concepts/policy-and-control/mixer-config.html). Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and infrastructure backends, abstracting the Envoy proxy and Istio-managed services from these details.
|
||||
|
||||
### Istio-Manager
|
||||
|
||||
[Istio-Manager]({{home}}/docs/concepts/traffic-management/manager.html) serves as an interface between the user and Istio, collecting and validating configuration and propagating it to the various Istio components.
|
||||
It abstracts environment-specific implementation details from Mixer and Envoy, providing them with an abstract representation of the user’s services
|
||||
that is independent of the underlying platform. In addition, traffic management rules (i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules) can
|
||||
be programmed at runtime via Istio-Manager.
|
||||
|
||||
### Istio-Auth
|
||||
|
||||
[Istio-Auth]({{home}}/docs/concepts/network-and-auth/auth.html) provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management.
|
||||
It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce policy based
|
||||
on service identity rather than network controls. Future releases of Istio will add fine-grained access control and auditing to control
|
||||
and monitor who accesses your service, API, or resource, using a variety of access control mechanisms, including attribute and
|
||||
role-based access control as well as authorization hooks.
|
||||
|
||||
|
||||
|
||||
## What's next
|
||||
|
||||
* Learn about Istio's [design goals](./goals.html).
|
||||
* Explore Istio's [high-level architecture](./architecture.html).
|
||||
* Explore and try deploying our [sample application]({{home}}/docs/samples/bookinfo.html).
|
||||
* Read about Istio components in detail in our other [Concepts]({{home}}/docs/concepts/) guides.
|
||||
* Learn how to deploy Istio with your own services using our [Tasks]({{home}}/docs/tasks/) guides.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue