|
1 | 1 | --- |
2 | | -title: Architecture |
3 | | -headline: Architecture |
| 2 | +title: What is Istio? |
| 3 | +headline: What is Istio? |
4 | 4 | sidenav: doc-side-concepts-nav.html |
5 | 5 | bodyclass: docs |
6 | 6 | layout: docs |
7 | 7 | type: markdown |
8 | 8 | --- |
9 | 9 |
|
10 | 10 | {% capture overview %} |
11 | | -The page explains in broad terms the major components of the Istio service mesh design. |
| 11 | +This page introduces Istio, a polyglot service mesh. |
12 | 12 | {% endcapture %} |
13 | 13 |
|
14 | 14 | {% capture body %} |
15 | | -## The proxy |
16 | | - |
17 | | -The Istio proxy is designed to mediate inbound and outbound |
18 | | -traffic for all Istio-managed services. The Istio proxy is based on |
19 | | -[Envoy](https://lyft.github.io/envoy/). Istio leverages Envoy's features |
20 | | -such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC |
21 | | -proxying, circuit breakers, health checks, staged rollouts with %-based |
22 | | -traffic split, fault injection, and a rich set of metrics. In addition, |
23 | | -Istio extends the proxy to interact with the mixer to enforce various |
24 | | -access control policies rate limiting, ACLs, as well as telemetry |
25 | | -reporting. |
26 | | - |
27 | | -## The mixer |
28 | | - |
29 | | -The Istio mixer is responsible for enforcing access control |
30 | | -and usage policies across the service mesh and collects telemetry data from |
31 | | -proxies and istio-managed services alike. The Istio proxy extracts request |
32 | | -level attributes that are then evaluated by the mixer. More info on the |
33 | | -attribute extraction and policy evaluation can be found |
34 | | -[here]({{site.baseurl}}/docs/reference/attribute-vocabulary.html). The mixer |
35 | | -includes a flexible plugin model enabling |
36 | | -it to interface to a variety of host environments and configured backends, |
37 | | -abstracting the proxy and Istio-managed services from these details. |
38 | | - |
39 | | -## The manager |
40 | | - |
41 | | -The Istio manager serves as an interface between the user |
42 | | -and Istio, collecting configuration, validating it and propagating it to |
43 | | -various components. It abstracts platform-specific implementation details |
44 | | -from the mixer and proxies, providing them with an |
45 | | -[abstract representation](model.md) of user's services that is independent |
46 | | -of the underlying platform. In addition, [traffic management rules](../reference/rule-dsl.md) |
47 | | -(i.e. generic layer-4 rules and layer-7 HTTP/gRPC routing rules) |
48 | | -can be programmed at runtime via the Istio Manager. |
| 15 | + |
| 16 | +## Context & Overview |
| 17 | + |
| 18 | +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. |
| 19 | + |
| 20 | +Istio provides a complete solution to satisfying 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 network of services: |
| 21 | + |
| 22 | +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. |
| 23 | +Observability - Gain understanding of the dependencies between services, the nature and flow of traffic between them and be able to quickly identify issues. |
| 24 | +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. |
| 25 | +Service identity and security - Provide services in the mesh with a verifiable identity [link] and provide the ability to protect [link] service traffic as it flows over networks of varying degrees of trustability. |
| 26 | + |
| 27 | +In addition to these behaviors, Istio is designed for extensibility to meet diverse deployment needs: |
| 28 | + |
| 29 | +Platform support - Istio is designed to run in a variety of environments including ones that span Cloud, on-premise, Kubernetes, Mesos etc. We’re initially focused on Kubernetes but are working to support other environments soon. |
| 30 | +Integration & Customization - The policy enforcement component can be extended [link] and customized [link] to integrate with existing solutions for ACLs, logging, monitoring, quotas, auditing and more. |
| 31 | + |
| 32 | +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. |
| 33 | + |
| 34 | +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|grpc|tcp|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. |
| 35 | + |
| 36 | +## Design Goals |
| 37 | +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. |
| 38 | + |
| 39 | +### Maximize transparency |
| 40 | +To adopt Istio an operator or developer should be required to do the minimum amount of work possible to get real value from the system. To this end Istio can automatically inject itself into all the network paths between services. Istio uses sidecar proxies to capture traffic and where possible automatically program the networking layer to route traffic through those proxies without any changes to the deployed application code. In Kubernetes the proxies are injected into pods and traffic is captured by programming iptables rules. Once the sidecar proxies are injected and traffic routing is programmed Istio is able to mediate all traffic. |
| 41 | + |
| 42 | +This principle also applies to performance. When applying Istio to a deployment operators should see a minimal increase in resource costs for the functionality being provided. Components and APIs must all be designed with performance and scale in mind. |
| 43 | + |
| 44 | +### Incrementality |
| 45 | +As operators and developers become more dependent on the functionality that Istio provides, the system must grow with their needs. While we expect to continue adding new features ourselves, we expect the greatest need will be the ability to extend the policy system, to integrate with other sources of policy and control and to propagate signals about mesh behavior to other systems for analysis. The policy runtime supports a standard extension mechanism for plugging in other services. In addition it allows for the extension of its vocabulary [[link]] to allow policies to be enforced based on new signals that the mesh produces. |
| 46 | +2.3 Portability |
| 47 | +The ecosystem in which Istio will be used varies along many dimensions. Istio must run on any cloud or on-prem environment with minimal effort. The task of porting Istio-based services to new environments should be trivial, and it should be possible to operate a single service deployed into multiple environments (on multiple clouds for redundancy for example) using Istio. |
| 48 | + |
| 49 | +### Policy Uniformity |
| 50 | +The application of policy to API calls between services provides a great deal of control over mesh behavior but it can be equally important to apply policies to resources which are not necessarily expressed at the API level. For example applying quota to the amount of CPU consumed by an 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, allowing services to directly integrate with it as needed. |
| 51 | + |
| 52 | +## High-Level Architecture |
49 | 53 |
|
50 | 54 | <img src="{{site.baseurl}}/img/arch.svg" alt="The overall architecture of an Istio-based service." /> |
| 55 | + |
| 56 | +### The Sidecar Model |
| 57 | + |
| 58 | +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. |
| 59 | + |
| 60 | +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. |
| 61 | + |
| 62 | +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. |
| 63 | + |
| 64 | +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. |
| 65 | + |
| 66 | +### Envoy |
| 67 | + |
| 68 | +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. |
| 69 | + |
| 70 | +### Mixer |
| 71 | + |
| 72 | +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 backends, abstracting the proxy and Istio-managed services from these details. |
| 73 | + |
| 74 | +### Istio Manager |
| 75 | + |
| 76 | +The 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 the Mixer and Proxy, 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 the Istio Manager. |
| 77 | + |
| 78 | +### Istio Auth |
| 79 | + |
| 80 | +Istio supports strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management. Istio Auth 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. |
| 81 | +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. |
| 82 | + |
| 83 | +Istio Auth is responsible for securing the service-to-service communication [link] and the end-user (mobile app, browser, etc.) to service communication [tbd]. It presents a strong service-level identity [link] to allow service-to-service interoperability across clusters and clouds. |
| 84 | +Istio-Auth provides a key management system [link] to automate key & certificate generation, distribution, and rotation. It enables end-to-end mutual TLS between microservices without any application code change. |
| 85 | +Istio-Auth provides fine-grained access control and auditing at different levels to control and monitor who accesses your service, api, and resource. It supports a variety of access control mechanisms, including attribute- and role-based access control as well as authorization hook [tbd]. |
| 86 | + |
51 | 87 | {% endcapture %} |
52 | 88 |
|
53 | 89 | {% include templates/concept.md %} |
0 commit comments