Istio 1.1 is enterprise-ready

It’s not far-fetched to say that Istio is one of the hottest open source projects right now; anyone who’s interested in microservices, containers and even serverless will find it useful.

It all began with the desire to offer an answer to the growing need for a service mesh within cloud-native environments and now, as Brian Harrington, Chief Architect at CoreOS wrote in a blog post last year, Istio is on the road of becoming “a category leading service mesh (essentially a configurable infrastructure layer for microservices) for Kubernetes.”

Today, we’re celebrating the release of Istio 1.1. Since this service mesh is beginning to receive more attention from the enterprise world, the team has worked hard to make sure companies using it have a smooth ride; that’s why the theme of this release is enterprise-ready.

Istio 1.1 highlights

If you’d like to see all the changes introduced in Istio 1.1, I invite you to read the release notes. If you want to skim through the release, then these highlights will come in handy:

Data plane and the control plane are now more efficient.
The team has done work around namespace isolation. You can now use Kubernetes namespaces to enforce boundaries of control and ensure that your teams cannot interfere with each other.
Improved multicluster capabilities and usability. There’s a new component called Galley, which validates YAML, therefore reducing the chance of configuration errors. Galley will also be instrumental in multicluster setups, gathering service discovery information from each Kubernetes cluster. The team is also supporting additional multicluster topologies including single control plane and multiple synchronized control planes without requiring a flat network.

Last but not least, since Istio has a lot of moving parts and can be a lot to take on, there’s now a Usability Working Group that you can join. You can also join the conversation at discuss.istio.io.

Installation

The team has increased the control plane and envoy sidecar’s required CPU and memory. It is critical to ensure your cluster have enough resource before proceeding the update.
Istio’s CRDs have been placed into their own Helm chart istio-init. This prevents loss of custom resource data, facilitates the upgrade process, and enables Istio to evolve beyond a Helm-based installation. The upgrade documentation provides the proper procedures for upgrading from Istio 1.0.6 to Istio 1.1. Please follow these instructions carefully when upgrading. If certmanager is desired, use the --set certmanager=true flag when installing both istio-init and Istio charts with either template or tillerinstallation modes.
The 1.0 istio-remote chart used for multicluster VPN and multicluster split horizon remote cluster installation has been consolidated into the Istio chart. To generate an equivalent istio-remote chart, use the --set global.istioRemote=true flag.
Addons are no longer exposed via separate load balancers. Instead, addons can now be optionally exposed via the Ingress Gateway. To expose an addon via the Ingress Gateway, follow the Remotely Accessing Telemetry Addons guide.
The built-in Istio Statsd collector has been removed. Istio retains the capability of integrating with your own Statsd collector, using the --set global.envoyStatsd.enabled=true flag.
The ingress series of options for configuring a Kubernetes Ingress have been removed. Kubernetes Ingress is still functional and can be enabled using the --set global.k8sIngress.enabled=true flag. Check out the Securing Kubernetes Ingress with Cert-Manager for how to secure your Kubernetes ingress resources.