Istio
| Developer(s) | Google,IBM,Lyft |
|---|---|
| Initial release | 18 November 2016[1] |
| Stable release | 1.0.2[2]
/ September 6, 2018 |
| Repository | github |
| Written in | Go |
| Engine | |
| Type | Mesh networking |
| License | Apache License 2.0 |
| Website | istio |
Search Istio on Amazon.
Istio [3] is a networking management control plane to dynamically monitor and control routing and access between services. The project was founded by Google, IBM, and Lyft in 2017[4] and incorporates lessons learned from both companies' experiences operating polyglot application stacks in production. Istio provides its functionality by deploying an out-of-process proxy (Envoy) alongside an existing application and forces the applications' calls to route through the proxy. These sidecars are then populated with routes and policies defined by a user from the Istio control plane. Since all traffic is now forced through the application's proxy, Istio can introspect protocol layer metrics, shape next hop routes, and automatically provide TLS encrypted communication between these enabled applications. By leveraging a sidecar, Istio features do not require maintenance of language specific libraries and supports developers in the exploration of different architectures and programming stacks.
History[edit]
- July 31 2018 - 1.0 production release[5]
- October 10 2017 - 0.2 First LTS release[6]
- May 24 2017 - First public release[7]
Core Features[edit]
Network Traffic Control[edit]
Istio configures request routing with VirtualServices . These rules indicate specific hosts via their FQDNs. The network traffic is then manipulated within the client's local Envoy before being sent to the downstream destination. Services reaching outside of Istio's mesh can be specified with a ServiceEntry, while inbound connections enter though an Istio Gateway
Traffic Splitting[edit]
Istio can balance requests by percentage based on arbitrary labels applied to a host and different subsets. This feature enables developers to send a proportion of traffic to one version of an application. Alternatively regex is supported to selectively direct a subset of users based on request data such as cookies or specific user-agents.[8]
Timeouts & Retries[edit]
Istio sets default timeouts for destinations but allows these to be overridden. Timeouts enable developers to fail early or late depending on their circumstance and can be leveraged to fallback to alternate error or fault scenarios.
Retries can be specified with a number of attempts and time between each attempt. A small number of retries can aid navigation through latency spikes or busy services that might otherwise fail the entire request.[9]
HTTP Fault Injection[edit]
Istio's fault injection capabilities allow for greater control over service timeouts and dependency testing. With configurable Timeouts&Retries operators can control maximum request processing time. This approach forces protocol-specific features like retries into the network layer [10].
Istio can also be used to test how a service behaves when dependencies are offline or timing out requests.[11] This is especially important when making requests to external services that may have unpredictable latency periods.
Application Tracing and Metrics Collection[edit]
Istio provides a uniform interface for exposing telemetry such as metrics and application traces collected by Envoy. Telemetry integrations are available for other open source collectors like Prometheus[12] and hosted solutions including Honeycomb.[13]
Protocol statistics including time of a HTTP request or number of bytes buffered are collected by Envoy. Statistics collected by the sidecars allow for a full analysis of a given connection or request.
Distributed traces are collected by Mixer and are aggregated based on a context-id supplied by the application. The application is responsible for creating and passing the unique ID between all services. An aggregation of the trace spans can be visualized with Zipkin or Lightstep.
Access Control and Secure Network Communication[edit]
Components[edit]
Envoy[edit]
Envoy is a C++11 out-of-process L7 proxy that is designed to run alongside an application server.[14] All traffic destined for a given application service must pass through the Envoy proxy before it is forwarded to the Envoy at the eventual destination. Envoy manipulates a payload by passing through a series of configurable listener, network, and HTTP filters.
Istio provides configuration to Envoy through a myriad of APIs conjointly referred to as xDS. Envoy & Mixer are data plane components within Istio.
Pilot[edit]
Pilot asynchronously configures the Envoy sidecar proxy that is deployed alongside an application. It leverages Envoy's xDS APIs to provide service discovery endpoints and specific rule sets to affect traffic shaping behavior.
Mixer[edit]
Mixer is a data plane component responsible for providing policy controls and telemetry collection. It is invoked to determine whether an incoming request is allowed to enter the system, and again in order to harvest and propagate telemetry once a request completes. Mixer interacts with existing 3rd party authorization and telemetry systems via an extensible set of adapters. Mixer's configuration model enables service operators fine-grained control over the behavior of the specific policies enforced and telemetry collected.
Although the specific policies enforced and telemetry collected is open-ended, common examples include policies for white list, black list, and quotas, while telemetry includes logs, metrics, and tracing.
Citadel[edit]
Citadel provides SPIFFE formatted certificate and key pairs to handle new Certificate Signing Requests or Kubernetes service accounts. These certificates are provided to Envoy along with the private key and are rotated on a period basis. These keys are leveraged for Mutual-TLS communication between Envoy and the services it proxies.
Galley[edit]
Galley is Istio's config ingestion and processing component. It listens to the Kubernetes API Server and validates, aggregates, transforms, and delivers configuration data to other Istio components.
References[edit]
- ↑ "First GitHub commit for Istio". github.com. 2016-11-18.
- ↑ "GitHub Releases page". github.com. 2018-09-10.
- ↑ "Istio". istio.io. Retrieved 2018-07-12.
- ↑ https://www.forbes.com/sites/janakirammsv/2017/05/25/google-ibm-and-lyft-want-to-simplify-microservices-management-with-istio/#366e5de75a4f
- ↑ https://www.ibm.com/blogs/cloud-computing/2018/07/31/ibm-google-open-community-istio-microservices//
- ↑ https://istio.io/blog/2017/0.2-announcement/
- ↑ https://techcrunch.com/2017/05/24/google-ibm-and-lyft-launch-istio-an-open-source-platform-for-managing-and-securing-microservices/
- ↑ https://istio.io/docs/concepts/traffic-management/#splitting-traffic-between-versions
- ↑ https://istio.io/docs/concepts/traffic-management/#timeouts-and-retries
- ↑ https://istio.io/docs/concepts/traffic-management/#fault-injection
- ↑ https://istio.io/docs/tasks/traffic-management/request-timeouts/
- ↑ https://dzone.com/articles/how-to-monitor-istio-the-kubernetes-service-mesh
- ↑ https://www.honeycomb.io/blog/2017/09/istio-envoy-and-honeycomb/
- ↑ https://www.envoyproxy.io/docs/envoy/v1.7.1/intro/what_is_envoy
This article "Istio" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Istio. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
