Announcing Istio 1.0
Istio is ready for production use with its 1.0 release.
Today, we’re excited to announce Istio 1.0! It’s been a little over a year since our initial 0.1 release. Since then, Istio has evolved significantly with the help of a thriving and growing community of contributors and users. We’ve now reached the point where many companies have successfully adopted Istio in production and have gotten real value from the insight and control it provides over their deployments. We’ve helped large enterprises and fast-moving startups like eBay, Auto Trader UK, Descartes Labs, HP FitStation, JUSPAY, Namely, PubNub and Trulia use Istio to connect, manage and secure their services from the ground up. Shipping this release as 1.0 is recognition that we’ve built a core set of functionality that our users can rely on for production use.
We’ve seen substantial growth in Istio’s ecosystem in the last year. Envoy continues its impressive growth and added numerous features that are crucial for a production quality service mesh. Observability providers like Datadog, SolarWinds, Sysdig, Google Stackdriver and Amazon CloudWatch have written plugins to integrate Istio with their products. Tigera, Aporeto, Cilium and Styra built extensions to our policy enforcement and networking capabilities. Red Hat built Kiali to wrap a nice user-experience around mesh management and observability. Cloud Foundry is building on Istio for it’s next generation traffic routing stack, the recently announced Knative serverless project is doing the same and Apigee announced that they plan to use it in their API management solution. These are just some of the integrations the community has added in the last year.
Since the 0.8 release we’ve added some important new features and more importantly marked many of our existing features as Beta signaling that they’re ready for production use. Here are some highlights:
Multiple Kubernetes clusters can now be added to a single mesh and enabling cross-cluster communication and consistent policy enforcement. Multicluster support is now Beta.
Networking APIs that enable fine grained control over the flow of traffic through a mesh are now Beta. Explicitly modeling ingress and egress concerns using Gateways allows operators to control the network topology and meet access security requirements at the edge.
Mutual TLS can now be rolled out incrementally without requiring all clients of a service to be updated. This is a critical feature that unblocks adoption in-place by existing production deployments.
Mixer now has support for developing out-of-process adapters. This will become the default way to extend Mixer over the coming releases and makes building adapters much simpler.
Authorization policies which control access to services are now entirely evaluated locally in Envoy increasing their performance and reliability.
Helm chart installation is now the recommended install method offering rich customization options to adopt Istio on your terms.
We’ve put a lot of effort into performance including continuous regression testing, large scale environment simulation and targeted fixes. We’re very happy with the results and will share more on this in detail in the coming weeks.
While this is a significant milestone for the project there’s lots more to do. In working with adopters we’ve gotten a lot of great feedback about what to focus next. We’ve heard consistent themes around support for hybrid-cloud, install modularity, richer networking features and scalability for massive deployments. We’ve already taken some of this feedback into account in the 1.0 release and we’ll continue to aggressively tackle this work in the coming months.
If you’re new to Istio and looking to use it for your deployment we’d love to hear from you. Take a look at our docs or stop by our chat forum. If you’d like to go deeper and contribute to the project come to one of our community meetings and say hello.
The Istio team would like to give huge thanks to everyone who has made a contribution to the project. It wouldn’t be where it is today without your help. The last year has been pretty amazing and we look forward to the next one with excitement about what we can achieve together as a community.
SNI Routing using Virtual Services. Newly introduced
VirtualServicecan be used to route TLS traffic based on SNI values. Service ports named as TLS/HTTPS can be used in conjunction with virtual service TLS routes. TLS/HTTPS ports without an accompanying virtual service will be treated as opaque TCP.
Streaming gRPC Restored. Istio 0.8 caused periodic termination of long running streaming gRPC connections. This has been fixed in 1.0.
Old (v1alpha1) Networking APIs Removed. Support for the old
v1alpha1traffic management model has been removed.
Istio Ingress Deprecated. The old Istio ingress is deprecated and disabled by default. We encourage users to use gateways instead.
Policy and telemetry
Updated Attributes. The set of attributes used to describe the source and destination of traffic have been completely revamped in order to be more precise and comprehensive.
Policy Check Cache. Mixer now features a large level 2 cache for policy checks, complementing the level 1 cache present in the sidecar proxy. This further reduces the average latency of externally-enforced policy checks.
Telemetry Buffering. Mixer now buffers report calls before dispatching to adapters, which gives an opportunity for adapters to process telemetry data in bigger chunks, reducing overall computational overhead in Mixer and its adapters.
Out of Process Adapters. Mixer now includes initial support for out-of-process adapters. This will be the recommended approach moving forward for integrating with Mixer. Initial documentation on how to build an out-of-process adapter is provided by the Out Of Process Adapter Dev Guide and the Out Of Process Adapter Walk-through.
Client-Side Telemetry. It’s now possible to collect telemetry from the client of an interaction, in addition to the server-side telemetry.
SignalFX. There is a new
stackdriveradapter has been substantially enhanced in this release to add new features and improve performance.
Authorization. We’ve reimplemented our authorization functionality. RPC-level authorization policies can now be implemented without the need for Mixer and Mixer adapters.
Improved Mutual TLS Authentication Control. It’s now easier to control mutual TLS authentication between services. We provide ‘PERMISSIVE’ mode so that you can incrementally turn on mutual TLS for your services. We removed service annotations and have a unique approach to turn on mutual TLS, coupled with client-side destination rules.
JWT Authentication. We now support JWT authentication which can be configured using authentication policies.
istioctl authn tls-checkcommand.
istioctl experimental convert-ingresscommand.
istioctl experimental convert-networking-configcommand.
Enhancements and bug fixes:
istioctl get allreturns all types of networking and authentication configuration.
istioctl getto retrieve resources across all namespaces.
Known issues with 1.0
Amazon’s EKS service does not implement automatic sidecar injection. Istio can be used in Amazon’s EKS by using manual injection for sidecars and turning off galley using the Helm parameter
In a multicluster deployment the mixer-telemetry and mixer-policy components do not connect to the Kubernetes API endpoints of any of the remote clusters. This results in a loss of telemetry fidelity as some of the metadata associated with workloads on remote clusters is incomplete.
There are Kubernetes manifests available for using Citadel standalone or with Citadel health checking enabled. There is not a Helm implementation of these modes. See Issue 6922 for more details.
Mesh expansion functionality, which lets you add raw VMs to a mesh is broken in 1.0. We’re expecting to produce a patch that fixes this problem within a few days.