13 Incorporating virtual machine workloads into the mesh

 

This chapter covers

  • Incorporating legacy workloads into Istio’s service mesh
  • Installing and configuring the istio-agent in VMs
  • Provisioning identity for VMs
  • Exposing cluster services to VMs, and vice versa
  • Using the local DNS proxy to resolve FQDNs of cluster services

So far, we’ve covered the Istio service mesh from the perspective of containers and Kubernetes. In reality, however, workloads frequently run on virtual machines (VMs) or physical machines. Containers and Kubernetes are often used in an effort to modernize a technology stack, and this chapter shows how to bridge these two worlds at the application-networking layer with Istio. You may wonder why we don’t simply modernize legacy workloads and run them in a Kubernetes cluster instead of integrating VMs into the mesh. We recommend that approach whenever it’s possible, but in a few cases it’s not—or at least, not when considering the cost:

  • Enterprises may have to run the workloads on-premises—due to regulatory compliance—where they lack the expertise to set up and operate Kubernetes clusters.
  • Containerizing applications is not that simple. Some apps may require rearchitecting; others might have dependencies that need to be updated but that conflict with other dependencies—dependency hell.
  • Some have some unique dependencies on the VM they run on.

13.1 Istio’s VM support

13.1.1 Simplifying sidecar proxy installation and configuration in a VM

13.1.2 Virtual machine high availability

13.1.3 DNS resolution of in-mesh services

13.2 Setting up the infrastructure

13.2.1 Setting up the service mesh

13.2.2 Provisioning the VM

13.3 Mesh expansion to VMs

13.3.1 Exposing istiod and cluster services to the VM

13.3.2 Representing a group of workloads with a WorkloadGroup

13.3.3 Installing and configuring the istio-agent in the VM

13.3.4 Routing traffic to cluster services

13.4 Demystifying the DNS proxy