Announcing Istio 1.8

We are pleased to announce the release of Istio 1.8!

This is our fourth and final release for 2020. We would like to thank the entire Istio team, and especially the release managers Greg Hanson from IBM and Pengyuan Bian from Google.

We continue to navigate in the direction outlined in our 2020 roadmap post, improving usability, security, reliability, with focus on multi-cluster meshes and VM workloads. We’ve introduced new features where necessary to further those goals, but in general, we’ve been focusing on bug fixes and polish — a theme we’ll be continuing into 2021.

Here are some highlights for this release:

Installing and Upgrading Istio

To codify all the knowledge on how to deploy and upgrade a mesh into software, we built the IstioOperator API and two different methods to install it - istioctl install and the Istio operator. However, some of our users have a deployment workflow for other software based on Helm, and so in this release we’ve added support for installing Istio with Helm 3. This includes both in-place upgrades and canary deployment of new control planes, after installing 1.8 or later. Helm 3 support is currently Alpha, so please try it out and give your feedback.

Given the several methods of installation that Istio now supports, we’ve added a which Istio installation method should I use? FAQ page to help users understand which method may be best suited to their particular use case.

Vendors can now provide optimized profiles for installing Istio on their platform. Installing Istio on OpenShift is easier as a result!

Multi-cluster

If you’re serious about reliability, you run more than one Kubernetes cluster. Setting up a mesh across multiple clusters used to take a lot of manual work, and you had a lot of permutations of choice as to how you wanted to run.

In this release, we’ve written a new installation guide which makes it easy to install a mesh that spans multiple clusters, with options depending on if the clusters are on the same network, and whether you want multiple control planes.

Easier to add VMs to your mesh

After making a number of security improvements to VM mesh endpoints in 1.7, we’ve focused on usability for 1.8. We simplified the installation process, and you can now use istioctl to do it. The new smart DNS proxying feature lets you resolve mesh services from your VMs, without having to insecurely point them at your cluster DNS server. It also reduces both cluster DNS traffic, and the number of look-ups needed to resolve a service’s IP. Auto registration allows you to tell the VM agent what kind of workload it has, and automatically have WorkloadEntry objects created for it when it joins the mesh.

Security and secrets

Certificates are now sent from Istiod to gateways, rather than them being read directly from Kubernetes. This reduces the privileges of gateways, which are often publicly exposed, improving our “defense in depth” security posture. Additionally, this opens the door for increased performance and lower memory footprint, and additional extensibility in certificate sources.

Istio ships with an out-of-the box Certificate Authority, but many users want to connect to an existing CA. Currently, you have to implement the Istio CSR API and write third-party integrations yourself. In Istio 1.8, we introduced an approach that leverages the Kubernetes CSR API and can be integrated with any tools that can use that API. Istiod provides the role of Registration Authority (RA) to authenticate and authorize a workload, then creates, approves, and monitors updates for a CSR resource. A third-party tool (e.g., cert-manager) can then apply the correct signer to create a signed certificate for with the appropriate backend CA. This feature is currently experimental.

Ease of use

Every release, our User Experience working group is making Istio easier to use.

When things break, we want to make it as easy as possible to help you fix them. In this release, we’ve introduced istioctl bug-report, which gathers debug information and cluster state, to make it easier for the developers or vendor support teams to understand.

istioctl analyze can now show where objects don’t validate properly, as well as cluster errors. In the case of an error, it will now return the exact line number of the error.

You can now refer to pods indirectly. No more istioctl dashboard envoy $(kubectl get pods -l app=productpage -o jsonpath="{.items[0].metadata.name}") - now it’s just istioctl dashboard envoy deployment/productpage.

Deprecations

Istio has been saying a long goodbye to the Mixer component, which is now removed in 1.8. If you still depend on any Mixer functionality, make sure to check the upgrade notes. You can still use the Mixer from 1.7 - but you should really get on the WebAssembly train!

Over the last two releases, we’ve changed how we package integrations addons (such as Prometheus, Zipkin, Jaeger and Kiali). Our bundled versions were not as powerful as those provided by the upstream authors, so we moved to providing upstream manifests instead of including them directly. Support for installing addons with Istioctl was deprecated in 1.7 and is removed in 1.8.

Join the Istio community

Our Community Meeting happens on the fourth Thursday of the month, at 10 AM Pacific. Due to US Thanksgiving, we’ve moved this month’s meeting forward one week to the 19th of November. If you can’t make it, why not join the conversation at Discuss Istio, or join our Slack workspace?

Would you like to get involved? Find and join one of our Working Groups and help make Istio even better.