Istio在设计之初，次要面向Kubernetes当中的服务。然而在理论场景中，仍旧有不少服务部署在VM上，Istio想成为Service Mesh事实上的规范，毫无疑问须要反对VM部署的服务。

Istio1.6 新增了 WorkloadEntry 自定义资源，通过该资源为VM提供了一流的反对。

Istio1.7 减少了平安疏导VM中运行的服务的身份的性能。最初，Istio 1.7减少了Sidecar的安装包，以反对CentOS/Red Hat和现有的Debian/Ubuntu。

Istio1.8 新增了智能 DNS 代理，它是由 Go 编写的 Istio sidecar 代理，sidecar 上的 Istio agent 将附带一个由 Istiod 动静编程的缓存 DNS 代理。来自应用程序的 DNS 查问会被 pod 或 VM 中的 Istio 代理通明地拦挡和服务，该代理会智能地响应 DNS 查问申请，能够实现虚拟机到服务网格的无缝多集群拜访。

并且Istio1.8新增了 WorkloadGroup 自定义资源，该资源是形容部署在VM上的服务实例的汇合，旨在模拟现有的用于Kubernetes工作负载的Sidecar注入和Deployment标准模型，以疏导Istio代理。

通过 WorkloadGroup形式， 实现VM 实例主动注册的性能目前处于pre-alpha状态

WorkloadEntry

WorkloadEntry用来形容非Pod的端点，将VM纳入mesh中。此时VM成为像Pod一样的一等公民，能够配置MUTUAL_TLS。

要创立一个WorkloadEntry并将其附加到ServiceEntry，执行以下操作:

apiVersion: networking.istio.io/v1alpha3kind: WorkloadEntrymetadata:  name: vm1  namespace: ns1spec:  address: 1.1.1.1  labels:    app: foo    instance-id: vm-78ad2    class: vm---apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: svc1  namespace: ns1spec:  hosts:  - svc1.internal.com  ports:  - number: 80    name: http    protocol: HTTP  resolution: STATIC  workloadSelector:    labels:      app: foo

这将创立一个蕴含一组标签和地址的新WorkloadEntry，以及一个应用WorkloadSelector抉择带有所需标签的所有端点的ServiceEntry，在这种状况下，包含为VM创立的WorkloadEntry。

请留神，ServiceEntry能够应用雷同的选择器援用Pod和WorkloadEntries。当初，Istio能够对VM和Pod进行雷同的解决，而不用将它们离开。

VM主动注册

WorkloadGroup次要用于 WorkloadEntry 主动注册，该性能在理论场景中比拟实用。事实上咱们部署在VM当中的服务，个别都会配置主动伸缩，这就要求咱们的服务必须能够主动注册到mesh中。

如何实现主动注册那？

首先咱们须要做一些筹备工作：

  • 在装置istiod的时候，启用主动注册的性能。
$ istioctl install --set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION=true
  • 部署一个east-west gateway。用于裸露istiod服务，从而能够让VM上的Sidecar 能够和istiod 通信。

而后咱们创立如下的 WorkloadGroup：

apiVersion: networking.istio.io/v1alpha3kind: WorkloadGroupmetadata:  name: python-http  namespace: vmspec:  metadata:    annotations: {}    labels:      app: python-http  template:    ports: {}    serviceAccount: my-vm

这样咱们在每个vm上python-http 实例启动后，都会主动在mesh中创立一个WorkloadEntry。而创立的WorkloadEntry，蕴含了VM实例的ip和元数据。此时咱们就能够创立一个ServiceEntry，通过标签选择器抉择咱们的WorkloadEntry。而后mesh中的其余服务就能够通过ServiceEntry中的hosts， 对咱们的python-http服务进行拜访。

apiVersion: networking.istio.io/v1beta1kind: ServiceEntrymetadata:  name: vm-workload-svc  namespace: vmspec:  hosts:  - vmservice.example.com  location: MESH_INTERNAL  ports:  - number: 80    name: http    protocol: HTTP    targetPort: 9090  resolution: STATIC  workloadSelector:    labels:      app: python-http

对于VM具体的装置步骤，参考官网文档。

智能DNS

其实实现VM主动注册，并不能通过主机名实现虚拟机到服务网格的无缝拜访。例如，如果咱们在VM上部署Istio sidecar代理，咱们将无奈通过主机名（例如httpbin.default.svc.cluster.local）拜访网格和Kubernetes集群中服务。此时咱们须要智能DNS。

在Istio 1.8中，Sidecar当初具备一个DNS代理，该代理缓存网格中的端点和ServiceEntry资源创立的端点。通过Iptables规定，拦挡dns申请到sidecar 本地dns server，在缓存中能够解析的主机名，则间接返回解析后果，如果找不到，它将作为一般DNS代理委派给零碎DNS。这样vm上的服务能够通过主机名拜访mesh中的服务。

智能DNS 默认没有启用，咱们在装置istio的时候，能够通过如下参数启用该性能：

--set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE=true

总结

当VM连贯到Istio管制立体时，它通过“东西向网关”进行连贯。该网关实际上只是一个专门为网格外部流量指定的Istio网关，当初，东西向网关曾经是Istio 1.8中的举荐部署。一旦从VM Sidecar到Istio管制立体建设了连贯，便会创立适当的WorkloadEntry资源，并使VM Sidecar能够解析集群中的所有服务。从VM上部署服务能够间接拜访httpbin.default.svc.cluster.local。 DNS名称由代理解析，并通过“东西方网关”路由到网格中的适当服务。