mirror of https://github.com/istio/istio.io.git
A bit of cleanup on the arch doc (#7323)
* A bit of cleanup on the arch doc * Replaced the confusing goals section with a minimal section on app's design * Removed trailing spaces * Clarfified sentence Co-authored-by: Adam Miller <1402860+adammil2000@users.noreply.github.com>
This commit is contained in:
Costin Manolache
GitHub
parent
879132e36e
commit
5b20fc424c
|
|
@ -25,12 +25,6 @@ The following diagram shows the different components that make up each plane:
|
|||
caption="Istio Architecture"
|
||||
>}}
|
||||
|
||||
Traffic in Istio is categorized as data plane traffic and control plane traffic.
|
||||
Data plane traffic refers to the messages that the business logic of the workloads
|
||||
send and receive. Control plane traffic refers to configuration and control messages sent
|
||||
between Istio components to program the behavior of the mesh. Traffic management
|
||||
in Istio refers exclusively to data plane traffic.
|
||||
|
||||
## Components
|
||||
|
||||
The following sections provide a brief overview of each of Istio's core components.
|
||||
|
|
@ -82,94 +76,41 @@ Some of the Istio features and tasks enabled by Envoy proxies include:
|
|||
* Pluggable extensions model based on WebAssembly that allows for custom policy
|
||||
enforcement and telemetry generation for mesh traffic.
|
||||
|
||||
### Pilot
|
||||
### Istiod
|
||||
|
||||
Pilot provides
|
||||
service discovery for the Envoy sidecars, traffic management capabilities
|
||||
for intelligent routing (e.g., A/B tests, canary rollouts, etc.),
|
||||
and resiliency (timeouts, retries, circuit breakers, etc.).
|
||||
Istiod provides service discovery, configuration and certificate management.
|
||||
|
||||
Pilot converts high level routing rules that control traffic behavior into
|
||||
Istiod converts high level routing rules that control traffic behavior into
|
||||
Envoy-specific configurations, and propagates them to the sidecars at runtime.
|
||||
Pilot abstracts platform-specific service discovery mechanisms and synthesizes
|
||||
them into a standard format that any sidecar conforming with the
|
||||
[Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) can consume.
|
||||
|
||||
The following diagram shows how the platform adapters and Envoy proxies
|
||||
interact.
|
||||
|
||||
{{< image width="40%" link="./discovery.svg" caption="Service discovery" >}}
|
||||
|
||||
1. The platform starts a new instance of a service which notifies its platform
|
||||
adapter.
|
||||
|
||||
1. The platform adapter registers the instance with the Pilot abstract model.
|
||||
|
||||
1. **Pilot** distributes traffic rules and configurations to the Envoy proxies
|
||||
to account for the change.
|
||||
|
||||
This loose coupling allows Istio to run on multiple environments such as Kubernetes,
|
||||
Consul, or Nomad, while maintaining the same operator interface for traffic
|
||||
management.
|
||||
Istio can support discovery for multiple environments such as Kubernetes,
|
||||
Consul, or VMs.
|
||||
|
||||
You can use Istio's
|
||||
[Traffic Management API](/docs/concepts/traffic-management/#introducing-istio-traffic-management)
|
||||
to instruct Pilot to refine the Envoy configuration to exercise more granular control
|
||||
to instruct Istiod to refine the Envoy configuration to exercise more granular control
|
||||
over the traffic in your service mesh.
|
||||
|
||||
### Citadel
|
||||
|
||||
[Citadel](/docs/concepts/security/) enables strong service-to-service and
|
||||
Istiod [security](/docs/concepts/security/) enables strong service-to-service and
|
||||
end-user authentication with built-in identity and credential management. You
|
||||
can use Citadel to upgrade unencrypted traffic in the service mesh. Using
|
||||
Citadel, operators can enforce policies based on service identity rather than
|
||||
can use Istio to upgrade unencrypted traffic in the service mesh. Using
|
||||
Istio, operators can enforce policies based on service identity rather than
|
||||
on relatively unstable layer 3 or layer 4 network identifiers. Starting from
|
||||
release 0.5, you can use [Istio's authorization feature](/docs/concepts/security/#authorization)
|
||||
to control who can access your services.
|
||||
|
||||
## Design goals
|
||||
Istiod maintains a CA and generates certificates to allow secure mTLS communication
|
||||
in the data plane.
|
||||
|
||||
A few key design goals informed Istio’s architecture. These goals are essential
|
||||
to making the system capable of dealing with services at scale and with high
|
||||
performance.
|
||||
## Application design
|
||||
|
||||
* **Maximize Transparency**: To adopt Istio, an operator or developer is
|
||||
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 {{<gloss pod>}}pods{{</gloss>}} and traffic is
|
||||
captured by programming ``iptables`` rules. Once the sidecar proxies are
|
||||
injected and traffic routing is programmed, Istio can mediate all traffic.
|
||||
This principle also applies to performance. When applying Istio to a
|
||||
deployment, operators 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.
|
||||
A design goal for Istio is that the developer can do minimum work
|
||||
to get real value from the system. Istio can automatically inject itself into
|
||||
the network paths between services and program the networking layer to
|
||||
securely route traffic and extract telemetry. If the application code
|
||||
uses TLS and uses its own policy and telemetry, Istio can only get minimal
|
||||
information from the encrypted communication between workloads.
|
||||
|
||||
* **Extensibility**: As operators and developers become more dependent on the
|
||||
functionality that Istio provides, the system must grow with their needs.
|
||||
While we continue to add new features, the greatest need is 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 to allow policies to be enforced based on new signals that the
|
||||
mesh produces.
|
||||
|
||||
* **Portability**: The ecosystem in which Istio is used varies along many
|
||||
dimensions. Istio must run on any cloud or on-premises environment with
|
||||
minimal effort. The task of porting Istio-based services to new environments
|
||||
must be trivial. Using Istio, you are able to operate a single service
|
||||
deployed into multiple environments. For example, you can deploy on multiple
|
||||
clouds for redundancy.
|
||||
|
||||
* **Policy Uniformity**: The application of policy to API calls between
|
||||
services provides a great deal of control over mesh behavior. However, it can
|
||||
be equally important to apply policies to resources which are not necessarily
|
||||
expressed at the API level. For example, applying a quota to the amount of
|
||||
CPU consumed by an ML training task is more useful than applying a quota to
|
||||
the call which initiated the work. To this end, Istio maintains the policy
|
||||
system as a distinct service with its own API rather than the policy system
|
||||
being baked into the proxy sidecar, allowing services to directly integrate
|
||||
with it as needed.
|
||||
|
|
|
|||
Loading…
Reference in New Issue