The latest Istio releases have been widely anticipated by users who want to extend the service mesh to their legacy workloads. Istio 1.7 laid some of the groundwork to make VMs first-class citizens in the mesh by making VMs look more like a pod in Istio. With its latest 1.8 release, Istio has resolved a key problem with DNS in the service mesh that has stood in the way of expanding the mesh to VMs and enabling seamless multicluster access and has continued to build on the groundwork laid in 1.7 to make VMs easier to enroll in the mesh. 

VMs in the Mesh

The smart DNS proxy transparently intercepts DNS queries from applications. As Shriram Rajagopalan explains in his blog, published on istio.io: 

“Starting with Istio 1.8, the Istio agent on the sidecar will ship with a caching DNS proxy, programmed dynamically by Istiod. Istiod pushes the hostname-to-IP-address mappings for all the services that the application may access based on the Kubernetes services and service entries in the cluster. DNS lookup queries from the application are transparently intercepted and served by the Istio agent in the pod or VM. If the query is for a service within the mesh, irrespective of the cluster that service is in, the agent responds directly to the application. If not, it forwards the query to the upstream name servers defined in /etc/resolv.conf.”

In addition to the smart DNS proxy, Istio 1.8 adds a WorkloadGroup, which describes a collection of workload instances that is intended for non-Kubernetes workloads. It provides a specification that the workload instances can use to bootstrap their proxies, including the metadata and identity. Using WorkloadGroups, Istio has started to help automate VM registration with the istioctl experimental workload group.

Tetrate, the enterprise service mesh company, uses these VM features extensively in customer deployments with a service mesh platform built for multi-cluster and multi-cloud. Pushing Istio to run everywhere is an important part of Tetrate’s founding mission.

Other new features…

• In response to user demand, Istio 1.8 reintroduces official support for Helm v3 for installations and upgrades. In previous versions, the installation was done with the istioctl command line tool or Istio Operator. With version 1.8, Istio supports in-place and canary upgrades with Helm in addition to the Operator and CLI-based installation methods.
  
• This release comes with a new installation guide to make it easier to install a mesh spanning multiple clusters, with options to run multiple control planes or multiple clusters on the same network. This update reduces the manual work required for setting up a mesh across multiple clusters.
• An experimental feature in 1.8 enables the integration of third-party CAs with the Istio ecosystem, leveraging the new Kubernetes certificate signing request (CSR) API. Istiod acts as the Registration Authority to authenticate and authorize workloads and manage updates for a CSR resource. This enables a third party like a cert-manager to create a signed certificate for the backend CA.
• The istioctl command-line tool has a new bug reporting feature (istioctl bug-report), which can be used to collect debugging information and get cluster status.
• R.I.P. Mixer: the component is fully deprecated in 1.8. For extensibility, you can use Envoy proxies and check out the GetEnvoy Toolkit that makes it easier for developers to create Wasm extensions for Envoy.
• Improved gateway certificates in 1.8 improve users’ security posture and will enable future improvements for fetching secrets.

About Tetrate

Tetrate is a top contributor to Istio, the de facto standard service mesh supported by a global open source community. Our products address the complexity of extending a service mesh across disparate systems. Built on top of Istio and Envoy, Tetrate Service Bridge connects applications and provides a management plane so that users can map their infrastructure to the needs and realities of their organization. Contact us if you’d like to discuss your large and complex deployment, or help create application-aware networking.

This blog was written by Tevah Platt and Jimmy Song and reviewed by Tetrate’s Zack Butcher.