Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Istio v1.0 Service Mesh Released with Feature “Ready for Production Use”

Istio v1.0 Service Mesh Released with Feature “Ready for Production Use”

Leia em Português

This item in japanese

At the Google Cloud Next 2018 event, held in San Francisco last week, the release schedule of the Istio v1.0 service mesh was announced. This week has seen the formal v1.0 release of the open platform that aims to make it easy to "create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code". Key new features include cross-cluster mesh support, fine-grained traffic flow control, and the ability to incrementally roll out mutual TLS across a mesh.

Istio is an open source platform that effectively acts as a control plane to the Envoy proxy data plane. Although Google appears to be leading the project, many other organisations are actively contributing, including Lyft (home of the Envoy proxy), IBM, Pivotal, Cisco, Red Hat and VMware.

The Istio control plane architecture consists of the Mixer for control and usage policies, Pilot for traffic management, and Citadel for identity and credential management. The Envoy data plane is deployed alongside services that are to be included within a mesh via the use of the sidecar pattern. All service-to-service communication is then intercepted by the Envoy sidecars, from which the policies specified in the control plane are enforced, and telemetry collected.

Istio service mesh architecture
Istio architecture (Image taken from Istio documentation)


The Istio blog announcement of the 1.0 release states that several new features have been added since the previous 0.8 release, and in addition the Istio team has "marked many of our existing features as Beta signaling that they're ready for production use" (although there has been some debate on Twitter about the meaning of "beta" in this context). The recommended method to install Istio into a Kubernetes cluster is now via the official Helm chart, although other options are documented. Installation guides are also provided for systems that use Docker and HashiCorp's Consul (and, although untested, a HashiCorp Nomad installation guide is also provided).

Multiple Kubernetes clusters can now be added to a single mesh, which enables "cross-cluster communication and consistent policy enforcement". This feature is beta, and the installation instructions caution that "a production environment might require additional steps or more complex deployment options." There is also an open issue (Istio issue #4822), in which a restart of any Istio service pod in the control plane cluster causes connections from remote clusters to break.

Also released in beta are Networking APIs that enable fine-grained control over the flow of traffic through a mesh. The documentation states that 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 (mTLS) can now be rolled out incrementally across a mesh without requiring all clients of an Istio-managed service to be updated in a big bang fashion. The Istio authentication policy provides a "PERMISSIVE" mode to overcome the issue of some services not having an Envoy sidecar to support communication via mTLS. Once this mode is enabled, a service can take both HTTP and mutual TLS traffic. After the migration is complete the permissive mode should be removed in order to enforce TLS on all communication within the mesh.

The Istio Mixer now has support for out-of-process adapters, which allows a developer to create "gRPC adapters" or "back-ends that expose a gRPC interface" that offers mixer functionality, such as logging, monitoring, quotas, ACL checking, and more. The release notes state that although the out-of-process adapter feature is currently under active development, this will become the default way to extend the Mixer over the coming releases, which will make building adapters much simpler.

Authorization policies, which control access to services, are now entirely evaluated locally in Envoy increasing their performance and reliability. Although the documentation does not elaborate, presumably there is some trade-off here with eventual consistency of data between the centralised Mixer and each service's Envoy proxy. The "Mixer and the SPOF Myth" documentation provides additional insight into this.

The release notes also state that the entire Istio community has put a lot of effort into performance and reliability, including continuous regression testing, large scale environment simulation and targeted fixes. Additional results of these tests will be shared "in detail in the coming weeks".

The official "Announcing Istio 1.0" blog post states that several organisations are exploring the use of Istio, including eBay, Auto Trader UK, Descartes Labs, HP FitStation, JUSPAY, Namely, PubNub and Trulia. The Google announcement article states there "are at least a dozen companies running Istio in production, including several on GCP", and includes a quote from Karl Stoney, delivery infrastructure lead at Auto Trader UK, who discusses how Istio has accelerated their move to containers and the public cloud:

Auto Trader UK is not only migrating from private cloud to public cloud, but also moving from virtual machines to Kubernetes. The level of control and visibility that Istio provides has enabled us to significantly de-risk this ambitious work

Last week at Google Cloud Next an alpha release of Managed Istio was also announced. This will be a deployment of the open-source Istio that is automatically installed and upgraded on a Kubernetes Engine cluster as a part of the Cloud Services Platform. Pivotal has also added support for Istio into their Cloud Foundry platform, with mTLS support available now, and ingress, additional service-to-service support and application security policies coming soon. The Pivotal Istio blog post also discusses that "abstractions matter", and "technology is at its best when it's invisible", and cautions developers to avoid focusing on the wrong things when building software and platforms that are intended to support the delivery of business value:

Developers may naturally be tempted to take on the task of using Istio and Kubernetes together, but this additional operational burden can come at a cost. Unless your core business is building and selling a platform, it's a waste of time and money. Your best and brightest engineers should be adding unique business value, not wiring up open-source components.

Additional companies are contributing to the Istio ecosystem. Observability providers like Datadog, SolarWinds, Sysdig, Google Stackdriver and Amazon CloudWatch have written plugins to integrate Istio with their products. Tigera, Cilium and Styra have built extensions to the policy enforcement and networking capabilities. Red Hat has also built Kiali, a web-based UI-driven tool that enables service mesh management and observability. Cloud Foundry is building on Istio for its 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.

Additional information on the v1.0 release of Istio can be found on the project's website at the release notes.

Rate this Article