Istio / FAQ

Istio 1.32 is now available! Click here to learn more
In your search for information about Istio and service mesh technology, we hope this FAQ helps!
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 The Istio service mesh
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 following the instructions on the getting started page, which installs a demonstration configuration along with Istio’s premier sample application, Bookinfo. You can then use this setup to walk through various Istio guides that showcase intelligent routing, policy enforcement, security, telemetry, etc., in a tutorial style.
To start using Istio with production Kubernetes deployments, please refer to our deployment models documentation and the which Istio installation method should I use? FAQ page.
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 to be platform-independent, initially focused on Kubernetes. For our 1.32 release, Istio supports environments running Kubernetes (1.33, 1.34, 1.35, 1.36, 1.37).
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 our discussion forum, Slack, and Stack Overflow.
Check out the documentation right here on istio.io. The docs include concept overviews, task guides, examples, and the complete reference documentation.
Detailed developer-level documentation is maintained on our Wiki
Check out the operations guide for finding solutions and our bug reporting page for filing bugs.
See our feature stages page and news for latest happenings.
It’s the Greek word for ‘sail’.
If you’d like to have live interactions with members of our community, you can join us on Istio’s Slack workspace.
In addition to the simple getting started evaluation install, there are several different methods you can use to install Istio. Which one you should use depends on your production requirements.
The following lists some of the pros and cons of each of the available methods:
Installs Istio from the command line using a built-in profile or an IstioOperator configuration file.
Allows easy integration with Helm-based workflows and automated resource pruning during upgrades.
Apply a generated Kubernetes manifest
This method is suitable where strict auditing or augmentation of output manifests is required, or there are third-party tooling constraints.
Installation instructions for all of these methods are available on the Istio install page.
Ensure that your cluster has met the prerequisites for the automatic sidecar injection. If your microservice is deployed in kube-system, kube-public or istio-system namespaces, they are exempted from automatic sidecar injection. Please use a different namespace instead.
Istio’s ztunnel does not introduce a single point of failure (SPOF) into a Kubernetes cluster. Failures of ztunnel are confined to a single node, which is considered a fallible component in a cluster. It behaves the same as other node-critical infrastructure running on every cluster such as the Linux kernel, container runtime, etc. In a properly designed system, node outages do not lead to cluster outages. Learn more.
You can change mutual TLS settings for your services at any time using authentication policy and destination rule. See task for more details.
Authentication policy can be mesh-wide (which affects all services in the mesh), namespace-wide (all services in the same namespace), or service specific. You can have policy or policies to set up mutual TLS for services in a cluster in any way as you want.
If you installed Istio with values.global.proxy.privileged=true, you can use tcpdump to determine encryption status. Also in Kubernetes 1.23 and later, as an alternative to installing Istio as privileged, you can use kubectl debug to run tcpdump in an ephemeral container. See Istio mutual TLS migration for instructions.
When STRICT mutual TLS is enabled, non-Istio workloads cannot communicate to Istio services, as they will not have a valid Istio client certificate.
If you need to allow these clients, the mutual TLS mode can be configured to PERMISSIVE, allowing both plaintext and mut