Istio诞生在kubernetes中，与kubernetes完美的融合同时又是kubernetes在微服务治理方向的补充，其基于PAAS平台基于网络的无侵入的微服务解决方案来构建Service Mesh体系是最大的亮点和价值之处。

问题：对于kubernetes以外的机器，特别是在企业微服务改造初期，必然会有一段云上云下共存的时期，在这段时间，一套微服务方案能够兼容和利旧就显得十分有必要。

在Istio官方的解决方案中目前可以在两个层面解决这个问题：
1.利用VirtualService，将外部服务创建为VirtualService，进而可以配置相应的外部服务配置访问规则，比如请求超时、故障注入等，从而实现对指定外部服务的控制访问。
2.为虚拟机安装istio，并将它与kubernetes中的istio连接起来，实现双向融合。

方案二大费周折在虚拟机中安装 Istio的意义在于方案一可以实现对容器到虚拟机服务方向的访问的管控，但是在这种方案下，对于虚拟机的服务是自成体系的，或者需要专门为虚拟机补充微服务方案，这种方法比较适用于老项目，利旧的场景下。虚拟机中安装 Istio，对于虚拟机中的服务对kubernetes容器服务方向的访问，也可以配置微服务策略，达到了解决方案的整体统一，这种方式比较适用于特殊业务需求场景无法容器化的场合，比如GPU需求或者其他特殊语言需求。

思考问题：
1.虚拟机如果有多个服务，该如何处理？
2.容器中的网络往往是自成体系的，虚拟机于容器的网络打通该如何处理？

纳管虚拟机还是istio一个比较新的特性 ，中间有很繁琐的配置和维护需求，网络也需要特殊处理，方案也不够成熟和普适，对比之下技术方向更应向方案一+虚拟机服务微服务特殊配置入手，或者通过对虚拟机部署轻量级的sidecar实现纳管。