Here are some frequently asked questions about Istio. If you don’t find your questions answered here, be sure to check Stack Overflow for more Q&A.
Istio is an open platform-independent service mesh that provides traffic management, policy enforcement, and telemetry collection.
Open: Istio is being developed and maintained as open-source software. We encourage contributions and feedback from the community at-large.
Platform-independent: Istio is not targeted at any specific deployment environment. During the initial stages of development, Istio will support Kubernetes-based deployments. However, Istio is being built to enable rapid and easy adaptation to other environments.
Service mesh: Istio is designed to manage communications between microservices and applications. Without requiring changes to the underlying services, Istio provides automated baseline traffic resilience, service metrics collection, distributed tracing, traffic encryption, protocol upgrades, and advanced routing functionality for all service-to-service communication.
For more detail, please see: What is Istio?
Traditionally, much of the logic handled by Istio has been built directly into applications. Across a fleet of services, managing updates to this communications logic can be a large burden. Istio provides an infrastructure-level solution to managing service communications.
Application developers: With Istio managing how traffic flows across their services, developers can focus exclusively on business logic and iterate quickly on new features.
Service operators: Istio enables policy enforcement and mesh monitoring from a single centralized control point, independent of application evolution. As a result, operators can ensure continuous policy compliance through a simplified management plane.
We recommend starting with the BookInfo sample, which walks through setting up a cluster with four distinct microservices managed by Istio. It exercises some basic features, including content-based routing, fault injection, and rate-limiting.
After you have mastered the BookInfo sample, you are ready to begin using Istio for your own services. To start using Istio on your existing Kubernetes cluster, please refer to our Installation task guide.
The Istio project was started by teams from Google and IBM in partnership with the Envoy team from Lyft. It’s been developed fully in the open on GitHub.
Istio is designed and built to be platform-independent. For our pre0.2 release, however, Istio only supports environments running Kubernetes v1.5 or greater.
Contributions are highly welcome. We look forward to community feedback, additions, and bug reports.
Detailed developer-level documentation is maintained for each component in GitHub, alongside the code. Please visit each repository for those docs:
Istio’s pre0.2 release provides an early preview of the intended functionality and user experience of our service mesh. We are hoping to solicit early feedback on direction and design decisions.
The pre0.2 release includes the following features:
Simple command-line installation into a Kubernetes cluster
Scripted proxy injection with traffic capture via iptables
L7 traffic routing rules
In-cluster load balancing for HTTP, gRPC & TCP
Cluster Ingress and Egress
In-memory rate limiting
L7 Metrics and Logs collection
Secure service-to-service authentication with strong identity
Pluggable policy layer and configuration API
See our release notes for more details.
Yes. The key and certificate distribution in Istio Auth is based on Kubernetes secrets.
Secrets have known security risks. The kubernetes team is working on several features to improve Kubernetes secret security, from secret encryption to node-level access control. And as of version 1.6, Kubernetes introduces RBAC authorization, which can provide fine-grained secrets management.
For pre0.2, we only support HTTP traffic. And we are actively working on supporting more kinds of traffic like SQL, etc.
Mixer provides a rich intermediation layer between the Istio components as well as Istio-based services, and the infrastructure backends used to perform access control checks and telemetry capture. This layer enables operators to have rich insights and control over service behavior without requiring changes to service binaries.
Mixer is designed as a stand-alone component, distinct from Envoy. This has numerous benefits:
Scalability. The work that Mixer and Envoy do is very different in nature, leading to different scalability requirements. Keeping the components separate enables independent component-appropriate scaling.
Resource Usage. Istio depends on being able to deploy many instances of its proxy, making it important to minimize the cost of each individual instance. Moving Mixer’s complex logic into a distinct component makes it possible for Envoy to remain svelte and agile.
Reliability. Mixer and its open-ended extensibility model represents the most complex parts of the data path processing pipeline. By hosting this functionality in Mixer rather than Envoy, it creates distinct failure domains which enables Envoy to continue operating even if Mixer fails, preventing outages.
Isolation. Mixer provides a level of insulation between Istio and the infrastructure backends. Each Envoy instance can be configured to have a very narrow scope of interaction, limiting the impact of potential attacks.
Extensibility. It was imperative to design a simple extensibility model to allow Istio to interoperate with as widest breath of backends as possible. Due to its design and language choice, Mixer is inherently easier to extend than Envoy is. The separation of concerns also makes it possible to use Istio policy and telemetry processing with different proxies, just as a mix of Envoy and NGINX.
Envoy implements sophisticated caching, batching, and prefetching, to largely mitigate the latency impact of needing to interact with Mixer on the request path.
It’s the Greek word for ‘sail’.