Icon Istio 0.2

General

  • Updated Configuration Model. Istio now uses the Kubernetes Custom Resource model to describe and store its configuration. When running in Kubernetes, configuration can now be optionally managed using the kubectl command.

  • Multiple Namespace Support. Istio control plane components are now in the dedicated “istio-system” namespace. Istio can manage services in other non-system namespaces.

  • Mesh Expansion. Initial support for adding non-Kubernetes services (in the form of VMs and/or physical machines) to a mesh. This is an early version of this feature and has some limitations (such as requiring a flat network across containers and VMs).

  • Multi-Environment Support. Initial support for using Istio in conjunction with other service registries including Consul and Eureka.

  • Automatic injection of sidecars. Istio sidecar can automatically be injected into a Pod upon deployment using the Initializers alpha feature in Kubernetes.

Performance and quality

There have been many performance and reliability improvements throughout the system. We don’t consider Istio 0.2 ready for production yet, but we’ve made excellent progress in that direction. Here are a few items of note:

  • Caching Client. The Mixer client library used by Envoy now provides caching for Check calls and batching for Report calls, considerably reducing end-to-end overhead.

  • Avoid Hot Restarts. The need to hot-restart Envoy has been mostly eliminated through effective use of LDS/RDS/CDS/EDS.

  • Reduced Memory Use. Significantly reduced the size of the sidecar helper agent, from 50Mb to 7Mb.

  • Improved Mixer Latency. Mixer now clearly delineates configuration-time vs. request-time computations, which avoids doing extra setup work at request-time for initial requests and thus delivers a smoother average latency. Better resource caching also contributes to better end-to-end performance.

  • Reduced Latency for Egress Traffic. We now forward traffic to external services directly from the sidecar.

Traffic management

  • Egress Rules. It’s now possible to specify routing rules for egress traffic.

  • New Protocols. Mesh-wide support for WebSocket connections, MongoDB proxying, and Kubernetes headless services.

  • Other Improvements. Ingress properly supports gRPC services, better support for health checks, and Jaeger tracing.

Policy enforcement & telemetry

  • Ingress Policies. In addition to east-west traffic supported in 0.1. policies can now be applied to north-south traffic.

  • Support for TCP Services. In addition to the HTTP-level policy controls available in 0.1, 0.2 introduces policy controls for TCP services.

  • New Mixer API. The API that Envoy uses to interact with Mixer has been completely redesigned for increased robustness, flexibility, and to support rich proxy-side caching and batching for increased performance.

  • New Mixer Adapter Model. A new adapter composition model makes it easier to extend Mixer by adding whole new classes of adapters via templates. This new model will serve as the foundational building block for many features in the future. See the Adapter Developer’s Guide to learn how to write adapters.

  • Improved Mixer Build Model. It’s now easier to build a Mixer binary that includes custom adapters.

  • Mixer Adapter Updates. The built-in adapters have all been rewritten to fit into the new adapter model. The stackdriver adapter has been added for this release. The experimental redisquota adapter has been removed in the 0.2 release, but is expected to come back in production quality for the 0.3 release.

  • Mixer Call Tracing. Calls between Envoy and Mixer can now be traced and analyzed in the Zipkin dashboard.

Security

  • Mutual TLS for TCP Traffic. In addition to HTTP traffic, mutual TLS is now supported for TCP traffic as well.

  • Identity Provisioning for VMs and Physical Machines. Auth supports a new mechanism using a per-node agent for identity provisioning. This agent runs on each node (VM / physical machine) and is responsible for generating and sending out the CSR (Certificate Signing Request) to get certificates from Istio CA.

  • Bring Your Own CA Certificates. Allows users to provide their own key and certificate for Istio CA.

  • Persistent CA Key/Certificate Storage. Istio CA now stores signing key/certificates in persistent storage to facilitate CA restarts.

Known issues

  • User may get periodical 404 when accessing the application: We have noticed that Envoy doesn’t get routes properly occasionally thus a 404 is returned to the user. We are actively working on this issue.

  • Istio Ingress or Egress reports ready before Pilot is actually ready: You can check the istio-ingress and istio-egress pods status in the istio-system namespace and wait a few seconds after all the Istio pods reach ready status. We are actively working on this issue.

  • A service with Istio Auth enabled can’t communicate with a service without Istio: This limitation will be removed in the near future.