方案介绍

应用现状

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

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

因为种种原因，容器与虚拟机共存将是一个长期的过程，但容器化的趋势不变。

在阶段二中，大量的虚拟机应用并不能很快容器化，人们通常会将新业务和少量应用率先实现容器化，并部署到Kubernetes中。在应用尚未完全实现容器化，处于过渡阶段时会遇到诸多问题，比如虚拟机上的非容器化服务是否可以像容器化服务一样进行流量治理？虚拟机如何访问容器中的服务？是否可以将容器和虚拟机纳入一个统一的控制平面来管理？

本文介绍一种通过为虚拟机安装代理来实现虚拟机治理的方案，可以有效解决以上几个问题。

解决方案

原理上网格可以提供对容器和虚拟机同等的治理能力，不同于Kubernetes容器上网格的数据面Proxy可以自动注入，自动流量拦截，基于Kubernetes的服务和实例模型自动进行服务发现，在虚拟机场景下需要手动安装数据面Proxy（ASM-PROXY），在安装过程中初始化流量拦截。具体来说，ASM-PROXY是虚拟机部署工具包，用于连接虚拟机应用所在的数据平面与ASM提供的控制平面。ASM-PROXY部署在虚拟机节点中，负责与ASM通信获取xDS信息，拦截非容器应用流量并执行网格化操作，例如流量管理、请求安全认证、上报链路追踪数据等。

在服务发现上，虚拟机形态的服务通过WorkloadEntry来描述一个虚拟机上安装了Proxy的实例，该虚拟机实例可以和Pod一样通过标签选择器被ServiceEntry选中和管理。

例如，ServiceEntry和三个WorkloadEntry的YAML文件如下：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: forecast
spec:
  hosts:
  - forecast
  location: MESH_INTERNAL
  ports:
  - number: 8080
    name: http
    protocol: HTTP
    targetPort: 8090
  resolution: STATIC
  workloadSelector:
    labels:
      app: forecast

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: forecast
spec:
  address: 192.168.1.3
  labels:
    app: forecast
    version: v1

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: forecast
spec:
  address: 192.168.1.4
  labels:
    app: forecast
    version: v1

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: forecast
spec:
  address: 192.168.1.5
  labels:
    app: forecast
    version: v2

那么ServiceEntry选择WorkloadEntry的机制可概括如下：