【51CTO.com快译】 Istio是一种流行的服务网格，用于连接、保护、控制和观察服务。Kubernetes于2017年作为开源系统首次亮相后，赢得了容器编排大战，Istio满足了向微服务迁移的组织的需要。虽然Istio声称支持Nomad、Consul、Eureka、Cloud Foundry和Mesos等异构环境，但实际上始终与Kubernetes协同运行最顺畅，毕竟Istio的服务发现基于Kubernetes。
Istio在开发初期因许多问题而饱受诟病：组件数量众多，安装和维护复杂，调试困难，因引入太多新概念和对象(多达50个CRD)而不易上手，Mixer组件给性能带来了影响。但是Istio团队在逐步解决这些问题。从2020年初发布的路线图可以看出，Istio已取得长足进展。
Istio团队今年的主要重点是将基于虚拟机的工作负载更好地整合到网格中。本文介绍了为什么Istio需要与虚拟机整合以及如何实现。
为什么Istio应支持虚拟机?
虽然容器和Kubernetes现已被广泛使用，但是仍有许多服务部署在需要由Istio网格管理的Kubernetes集群之外的虚拟机和API上。将旧环境与新环境的管理统一起来是个巨大挑战。
将虚拟机添加到网格需要什么?
介绍如何添加之前，先介绍将虚拟机添加到网格需要什么。支持虚拟机流量时，Istio须了解以下几点：哪些虚拟机拥有应是网格一部分的服务?如何访问虚拟机?每个虚拟机还需要身份，以便与网格的其余部分安全地联系。这些要求与Kubernetes CRD以及像Consul这种功能完备的服务注册中心(Service Registry)兼容。而基于服务帐户的身份引导可充当为没有平台身份的虚拟机分配工作负载身份的机制。对于确实有平台身份的虚拟机(比如EC2、GCP或Azure等)，Istio正致力于将Kubernetes身份与平台身份进行交换，以便建立mTLS通信。
Istio如何支持虚拟机?
Istio支持虚拟机始于其服务注册机制。Istio网格中有关服务和实例的信息来自Istio的服务注册中心，到目前为止，服务注册中心只查看或跟踪pod。在较新版本中，Istio现在拥有用于跟踪和监测虚拟机的资源类型。网格内的边车(sidecar)无法观察和控制进入到网格外服务的流量，因为它们没有任何关于它们的信息。
Istio社区在Istio支持虚拟机方面做了很多的工作。1.6版本增加了WorkloadEntry，使您可以像描述Kubernetes中运行的主机那样描述虚拟机。在1.7版本中，该版本开始通过令牌将引导虚拟机的基础自动添加到网格中，Istio处理繁重的任务。Istio 1.8将首次引入名为WorkloadGroup的另一个抽象，它类似Kubernetes Deployment对象，不过面向虚拟机。
下图显示了Istio如何为网格中的服务建模。信息的主要来源来自平台服务注册中心(比如Kubernetes)或系统(比如Consul)。另外，ServiceEntry充当用户定义的服务注册中心，可为虚拟机上的服务或组织外的外部服务建模。
Istio中的服务注册模型
既然只要使用ServiceEntry就可以在虚拟机中引入服务，为什么在虚拟机中安装Istio?
使用ServiceEntry，您可以启用网格内的服务来发现和访问外部服务，并管理进入到那些外部服务的流量。与VirtualService结合使用，您还可以配置相应外部服务的访问规则(比如请求超时和故障注入等)，从而实现有控制地访问指定的外部服务。
即便如此，它也只能控制客户端上的流量，无法控制对引入到其他服务的外部服务的访问。也就是说，它无法控制作为呼叫发起者的服务的行为。在虚拟机中部署边车，并通过工作负载选择器引入虚拟机工作负载，让虚拟机可以随意加以管理，就像Kubernetes中的pod那样。
展望未来
从bookinfo演示(https://istio.io/latest/docs/examples/virtual-machines/bookinfo/)可以看到，这个过程涉及太多的手动工作，很容易出错。将来，Istio将提高虚拟机测试的逼真度，基于平台身份实现自动引导，改善DNS支持和istioctl调试等。您可以关注Istio环境工作组(https://github.com/istio/community/blob/master/WORKING-GROUPS.md)，以获得有关虚拟机支持的更多详细信息。
原文标题：How to Integrate Virtual Machines into Istio Service Mesh，作者：Jimmy Song
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
