Virtual Service

上一节讲到如何创建Gateway，这个网关配置让 HTTP 流量从 bookinfo.app域名通过 80 端口流入网格，但没有为请求指定任何路由规则。例如/productpage的流量不能流到后端的service：

image-20220809230336556

这些路由规则与后端服务的映射，是通过VirtualService来实现的：

image-20220809230543416

创建一个yaml定义：

image-20220809231346092

里面声明如下：

  • hosts部分：匹配bookinfo.app域名
  • gateways部分：对应上一节创建的bookinfo-gateway
  • http match部分：匹配url——可以精确匹配，也可以用前缀匹配
  • http route部分：将流量转向productpage后端服务

使用VirtualService进行流量控制

上面提到了VirtualService可以把网关(Gateway)的流量解析到具体后端服务，但它的功能不仅限于此。它还可以进行流量的控制

有时候测试新版本的应用上线，需要做A/B测试，例如原来的版本是v1，现在需要将一部分流量导入到新版本v2进行测试：

image-20220809232029948

在K8s原生实现中，我们是这样做的，定义一个service，然后它的selector是app=reviews：

image-20220809232350255

创建新版本的deployment，它的label依然是app=reviews:

image-20220809232531001

v2版本的replica数量是1，v1版本的replica数量是3，所以reviews service会将25%的流量导入到v2版本。

如果v2版本测试没问题，我们可以将v1版本下掉，这样100%的流量会进入v2版本：

kubectl scale deployment reviews-v2 --replicas=3
kubectl scale deployment reviews-v1 --replicas=0

这样做AB测试很简单且易实现，但唯一的问题是不好做细粒度的流量控制，例如想导入1%流量到v2版本，我们需要创建99个v1版本的pod和1个v2版本的pod。

VirtualService可以帮我们解决上面的精准流量控制问题，这在 A/B 测试中可能有用——您可能希望在其中配置基于不同服务版本的流量百分比路由:

image-20220809233113191