【.com速译】Istio是一个流行的服务网格，用于连接、保护、控制和观察服务。在2017年Kubernetes作为开源系统首次亮相并赢得容器编排大战之后，Istio满足了组织迁移到微服务的需求。尽管Istio声称支持Nomad、Consul、Eureka、CloudFoundry和Mesos等异构环境，但实际上它始终与Kubernetes配合使用效果最佳。毕竟Istio的服务发现是基于Kubernetes的。Istio在发展初期被诟病的问题很多：组件数量多，安装维护复杂，调试困难，引入了太多新概念和新对象（多达50个），上手不易CRD）。Mixer组件带来性能影响。但Istio团队正在逐步解决这些问题。从2020年初发布的路线图中可以看出，Istio已经取得了长足的进步。Istio团队今年的主要工作重点是更好地将基于虚拟机的工作负载集成到网格中。本文解释了为什么Istio需要与虚拟机集成以及如何集成。为什么Istio应该支持虚拟机？虽然现在容器和Kubernetes被广泛使用，但仍有许多服务部署在Kubernetes集群之外的虚拟机和API上，需要通过Istio网格进行管理。将旧环境与新环境统一管理是一个巨大的挑战。将虚拟机添加到网格需要什么？在我们解释如何之前，让我们先谈谈将虚拟机添加到网格需要什么。当支持VM流量时，Istio必须了解以下内容：哪些VM拥有应该成为网格一部分的服务？如何访问虚拟机？每个VM还需要一个身份，以便与网格的其余部分进行安全通信。这些要求与KubernetesCRD和功能齐全的服务注册中心（如Consul）兼容。相反，基于服务帐户的身份引导可作为一种机制，将工作负载身份分配给没有平台身份的虚拟机。对于确实具有平台身份（例如EC2、GCP或Azure等）的虚拟机，Istio正在致力于将Kubernetes身份与平台身份进行交换，以建立mTLS通信。Istio如何支持虚拟机？Istio对虚拟机的支持始于其服务注册机制。Istio网格中有关服务和实例的信息来自Istio的服务注册表，到目前为止它只查看或跟踪pod。在较新的版本中，Istio现在具有用于跟踪和监控虚拟机的资源类型。网格内的边车无法观察和控制流向网格外服务的流量，因为它们没有任何关于服务的信息。Istio社区在Istio对虚拟机的支持方面做了很多工作。1.6版本增加了WorkloadEntry，它允许您像描述运行在Kubernetes中的主机一样描述虚拟机。在1.7版本中，开始通过令牌自动将引导VM的基础添加到网格中，Istio负责处理繁重的工作。Istio1.8将首次引入另一个名为WorkloadGroup的抽象，它类似于KubernetesDeployment对象，但用于虚拟机。下图显示了Istio如何在网格中建模服务。信息的主要来源来自平台服务注册中心（如Kubernetes）或系统（如Consul）。此外，ServiceEntry充当用户定义的服务注册中心，可以对虚拟机上的服务或组织外部的外部服务进行建模。Istio中的服务注册模型既然只需要使用ServiceEntry就可以在虚拟机中引入服务，那为什么还要在虚拟机中安装Istio呢？使用ServiceEntry，您可以使网格中的服务能够发现和访问外部服务，并管理对这些外部服务流量的访问。结合VirtualService，还可以为相应的外部服务配置访问规则（如请求超时、故障注入等），从而实现对指定外部服务的访问受控。即使这样，它也只能控制客户端的流量，而不能访问引入其他服务的外部服务。也就是说，它无法控制发起调用的服务的行为。在虚拟机中部署sidecars，通过workloadselector引入虚拟机工作负载，这样就可以随意管理虚拟机，就像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)以获取有关虚拟机支持的更多详细信息。原标题：如何将虚拟机集成到IstioServiceMesh，作者：JimmySong
