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 Guides, which walks through different core Istio concepts in a tutorial style. The guides show case intelligent routing, policy enforcement, security, telemetry, etc.
To start using Istio on your existing Kubernetes or Consul deployment, please refer to our Installation task guide.
Istio uses the Apache License 2.0.
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 0.2 release, Istio supports environments running container orchestration platforms such as Kubernetes (v1.7.4 or greater) and Nomad (with Consul).
Contributions are highly welcome. We look forward to community feedback, additions, and bug reports.
The code repositories are hosted on GitHub. Please see our Contribution Guidelines to learn how to contribute.
In addition to the code, there are other ways to contribute to the Istio community, including on Stack Overflow, and the mailing list.
If you’d like to speak to the Istio team about a potential integration and/or a partnership opportunity, please complete this form.
Check out the documentation right here on istio.io. The docs include concept overviews, task guides, guides, and the complete reference documentation.
Detailed developer-level documentation is maintained for each component in GitHub, alongside the code. Please visit each repository for those docs:
Check out the troubleshooting guide for finding solutions and our bug reporting page for filing bugs.
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.
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.
Istio’s initial 0.1 release was in May of 2017. The 0.1 release was to get early feedback and provide a glimpse into what we’re planning.
Istio’s second release, 0.2, was in October of 2017. The 0.2 release provides a much enhanced developer experience and a number of exciting new features.
See our roadmap and release notes for more details.
It’s the Greek word for ‘sail’.