Istio 对虚拟机支持史话

本文将为你介绍 Istio 历史上对虚拟机负载的支持情况，尤其是 Istio 1.8 中引入的智能 DNS 代理及使得虚拟机与容器在资源抽象层面可以等同视之。我将为你展现一幅 Istio 支持虚拟机的波澜壮阔的奥德赛。

本文也是我去年12 月 20 日在云原生社区 北京站上的分享的话题内容之一，原文是英文版发布在 上，本文是中文版。

前言

在我之前的博客[1]中谈到 Istio 1.7 如何支持虚拟机，但那时虚拟机仍然无法无缝的集成到 Istio 中，因为还需要做很多手动的操作。现在，Istio 1.8 新增了 及智能 DNS 代理[2]，这使得如虚拟机这样的非 工作负载可以在 Istio 中成为像 Pod 一样的一等公民。

不论有没有为虚拟机安装 ，虚拟机通常情况下无法直接访问 集群中的 DNS 服务器以解析 服务的 IP 的（虽然你也许可以通过一些黑客的手段做到），这是在 Istio 中集成虚拟的最后一块短板，终于在 Istio 1.8 中完成了突破。

为什么要支持虚拟机？

在我们将应用在迁移到云原生架构，不断容器化的过程中，将经历三个阶段，如下图所示。

云原生应用的三个阶段

•阶段一：应用全部部署在虚拟机上•阶段二：应用既部署在虚拟机上也部署在容器里，正在从虚拟机向容器中迁移，并使用 管理容器•阶段三：所有的应用优先部署在容器里，使用 管理容器，使用 Istio 管理应用间的通信

上图仅是对以上三个阶段的最简化描述，实际上还会有多混合云、多机房、多集群等情况，且阶段三只是个理想化的阶段，容器和虚拟机将是长期共存的，但是容器化趋势不变。

在阶段二中，人们通常会将新业务和少量应用率先实现容器化，并部署到 中，在应用尚未完全实现容器化的时候，处于过度状态时会遇到很多问题，如何让应用与部署在虚拟机中的服务交互？虚拟机如何访问容器中的服务？在服务迁移的过程中如何保证稳定无缝？是否可以将容器和虚拟机纳入一个统一的控制平面来管理？Istio 从开源初期就考虑并着手解决这一问题。

Istio 支持虚拟机的历史

Istio 对于虚拟机的支持是个漫长的过程，堪称是一部奥德赛。

Istio mesh 扩张

Istio 从 0.2 版本开始通过Istio Mesh [3]将虚拟机加入的 Mesh 中，但是需要满足以下前提条件：

•虚拟机必须可以通过 IP 地址直接访问到应用的 Pod，这就要求容器与 VM 之间通过 VPC 或者 VPN 建立扁平网络，虚拟机不需要访问 IP，直接对服务的 端点访问即可。•虚拟机必须可以访问到 Istio 的控制平面服务（Pilot、Mixer、CA，现在已正整合为 ），可以通过在 Istio Mesh 中部署负载均衡器将控制平面端点暴露给虚拟机。•（可选）虚拟机可以访问到 Mesh 内部的（部署在 中）的 DNS 。

集成虚拟机的步骤如下：

1.为 Istio 控制平面服务及 集群的 DNS 服务创建 负载均衡器；2.生成 Istio CIDR、 token、安全证书、Istio 控制平面服务的 IP（通过 负载均衡器暴露出来的 IP）的配置文件并发送给虚拟机；3.（可选）在虚拟机中安装、配置并启动 Istio 的组件、（用于 DNS 发现），此时虚拟机可以使用 FQDN 访问 mesh 中的服务了，这一步是为了保证虚拟机可以正确解析出 mesh 中服务的 IP；4.若要在虚拟机中运行服务，需要配置 ，新增需要拦截的 端口，然后重启 istio，还需要运行 为服务注册

下图展示的从集成虚拟机到在 mesh 中访问虚拟机中服务的详细流程。

图一：从集成虚拟机到在 mesh 中访问虚拟机中服务的详细流程

1.DNS 被虚拟机中部署的劫持，这使得它可以正确的获取 Istio 服务、 内置 DNS 的端点 IP；2.访问 的内置 DNS 服务（该服务已通过 负载均衡器暴露到集群外，可以直接访问）；3.返回..svc..local被解析出来的 IP，注意该 IP 地址无法直接访问，但是如果无法被 DNS 解析的话将导致 VM 对该服务的请求失败；4.虚拟机对 mesh 中服务的访问被 proxy 劫持；5.因为 proxy 已连接 Istio 控制平面，可通过 xDS 查询到该服务的端点，因此流量将被转发到其中的一个端点。关于这一步的详细过程请参考Istio 中的 流量路由机制分析 一节[4]；6.要想在 mesh 中访问 VM 中的服务，需要使用 命令手动将 VM 中的服务添加到 mesh 中，这本质上是将 VM 中的服务，注册到 中的 和 ；7.mesh 中的服务可以使用 VM 注册的服务名称（FQDN，例如mysql.vm.svc..local）来访问；

以上 Istio 对虚拟机支持的方式一直延续到 Istio 1.0，在 Istio 1.1 的时候引入了新的 [5]，使用它可以在 Istio 的内部服务注册表中添加额外的条目，这样 mesh 中的服务就可以访问 / 路由到这些手动指定的服务了，不再需要运行 命令，而且该命令在 Istio 1.9 中将被废弃。

Istio 1.5 中增加了 add-to-mesh命令，可以将虚拟机中的服务添加到 mesh 中，其功能与 一样。

新增资源抽象

Istio 从1.6 版本[6]开始在流量管理[7]中引入了新的资源类型[8]，用以将虚拟机进行抽象，使得虚拟机在加入 mesh 后可以作为与 中的 Pod 等同的负载，具备流量管理、安全管理、可视化等能力。通过可以简化虚拟机的网格化配置过程。对象可以根据服务条目中指定的标签选择器选择多个工作负载条目和 pod。

Istio 1.8 中增加了[9]的资源对象，它提供了一个规范，可以同时包括虚拟机和 工作负载，旨在模仿现有的用于 工作负载的 注入和部署规范模型来引导 Istio 代理。

下面是虚拟机与 中负载的资源抽象层级对比。

从上面的图表中我们可以看到，对于虚拟机工作负载是可以与 中的负载一一对对应的。

此时看似一切都比较完美了，但是直接将 集群中的 DNS 暴露出来会带来很大的安全风险[10]，因此我们一般手动将虚拟机需要访问的服务的域名和 IP 对写到本机的/etc/hosts中，但是对于一个节点数量庞大的分布式集群来说，这种做法又有些不现实。

通过配置虚拟机本地/etc/hosts访问 mesh 内服务的流程，如下图所示。

图二：通过配置虚拟机本地 /etc/hosts 访问 mesh 内服务的流程

1.将虚拟机中的服务注册到 mesh 中；2.将要访问的服务的域名、 IP 对手动写入虚拟机本地的/etc/hosts文件中；3.虚拟机获得访问服务的 IP；4.流量被 proxy 拦截并解析出要访问的服务的端点地址；5.访问服务的指定端点；

在 中我们一般使用 对象来实现服务的注册和发现，每个服务都有一个独立的 DNS 名称，应用程序可以使用服务名称来互相调用。我们可以使用 将虚拟机中的服务注册到 Istio 的服务注册表中，但是在 集群中的 DNS 无法对 mesh 外部暴露的情况下，虚拟机无法访问 集群中的 DNS 服务以获取服务的 IP，从而导致虚拟机访问 mesh 中的服务失败。如果能在虚拟机中增加一个 可以透明地拦截 DNS 请求，可获取 mesh 内所有服务的 ，类似于图一中的的角色，这样不就可以解决问题了吗？

智能 DNS 代理

Istio 1.8 中引入了智能 DNS 代理[11]，虚拟机访问 mesh 内服务无需再配置/ect/hosts，如下图所示。

图三：引入了智能 DNS 代理后虚拟机访问 mesh 内服务的流程

DNS proxy 是用 Go 编写的 Istio 代理。 上的 Istio agent 将附带一个由 动态编程的缓存 DNS 代理。来自应用程序的 DNS 查询会被 pod 或 VM 中的 Istio 代理透明地拦截和服务，该代理会智能地响应 DNS 查询请求，可以实现虚拟机到服务网格的无缝多集群访问。

至此，Istio 1.8 中引入的 及智能 DNS 代理，补足了 Istio 对虚拟机支持的最后一块短板，使得部署在虚拟机中的遗留应用可以跟 中的 Pod 一样完全等同看待。

总结

在这部 Istio 支持虚拟机的奥德赛中，我们可以看到：从最初的将 mesh 中的 DNS 暴露给外部，在虚拟机中安装配置，到最后的使用智能 DNS 代理，并使用、和等资源抽象，逐步实现了虚拟机和 pod 的统一管理。本文仅仅是针对单集群的情况，在实际的生产中使用还远远不够，我们还需要处理安全、多集群、多租户等诸多问题，欢迎关注 的旗舰产品 [12]了解更多关于 Istio 应用在生产上的最佳实践。

引用链接

[1]之前的博客:

[2]智能 DNS 代理:

[3]Istio Mesh :

[4]Istio 中的 流量路由机制分析 一节:

[5]:

[6]1.6 版本:

[7]流量管理:

[8]:

[9]:

[10]安全风险:

[11]智能 DNS 代理:

[12] :

加入云原生社区 Istio SIG

扫描下面的二维码加入云原生社区 Istio SIG， 与 Istio 专家及爱好者们共同交流。