The team behind service mesh Istio has released version 1.8 of its project. The last major update of the year showcases further advances of the Istio User Experience working group and improves on some security aspects.
For example, the mesh has stopped reading certificates directly from Kubernetes and now sends them from Istiod to gateways instead. The approach supposedly makes the often publicly exposed gateways less of a risk factor while also upping performance.
Version 1.8 also looks to allow users to connect to certificate authorities besides the one that Istio ships with. This is done using the Kubernetes CSR API, while Istiod serves as a registration authority to authenticate and authorise workloads. The experimental feature allows any third party tool working with the Kubernetes CSR API to create a signed certificate for the appropriate backend CA, making it easier to integrate into a more complex workflow.
In terms of usability, the Istio team has worked a bit to make meshes easier to debug, adding a bug report with debug information and the cluster state to istioctl. It also adjusted the command line utility’s analyze tool to show the line number for cases in which objects don’t validate properly and made the dashboard more user friendly by allowing something like istioctl dashboard envoy deployment/productpage to refer to pods indirectly.
Easy installation and good documentation still play a major role when it comes to convincing organisations to buy into an open source project. Istio has done a lot in this regard lately, so version 1.8 includes a new guide for installing multiple cluster-spanning meshes and help when using virtual machine mesh endpoints. Those can now be installed via istioctl, though there are also auto registration and a smart DNS proxying feature available to simplify things further.
Smart proxying promises to “resolve mesh services from your VMs, without having to insecurely point them at your cluster DNS server”, though the reduction of cluster DNS traffic and the number of look-ups to resolve a service’s IP address are nice side effects. Auto registration also pretty much does what it says on the tin, leading to Istio automatically creating WorkloadEntry objects for a VM agent when it joins a mesh.
Istio 1.8 also is the first version to sport experimental support for using Helm 3. The latter complements istioctl install and the Istio operator for installation purposes and is meant to get more teams on board who have built their software deployment workflow on Helm.
However, the new addition seemingly makes things more complicated for those new to the container game as it can be hard to figure out which approach is best for a given scenario. For that reason the Istio website now sports a FAQ section pointing out pros and cons of each method.
Users whose setup still depends on the Mixer component should note that it was removed with the latest Istio release. To make sure extensions keep working, they will therefore either have to be migrated to web assembly or the Envoy authorisation and access log services will have to be enabled, so that Mixer 1.7 can still be used. Help with that can be found in the Istio wiki.