一、VirtualService资源
VirtualService(虚拟服务)在增强Istio流量管理的灵活性和有效性方面发挥着至关重要的作用。Virtualservice由一组路由规则组成,用于对服务实体(在Kubernetes中对应为Pod)进行寻址。如果有流量命中了某条路有规则,就会将其发送到对应的服务或者服务的一个版本/子集。
VirtualService描述了用户可寻址目标到网格内实际工作负载之间的映射。可寻址的目标服务使用hosts字段来指定,而网格内的实际负载由每个route配置项中destination字段来指定。
VirtualServcie通过对客户端请求的目标地址与真实响应请求的目标工作负载进行解耦来实现。
VirtualService同时提供来丰富的配置方式,为发送至这些工作负载的流量指定不同的路由规则。
如果没有Virtualservice,Envoy会以轮询的方式在所有的服务实例中分发请求。可以根据具体的工作负载来改进这种行为。例如,有些工作负载代表不同的版本。这在A/B测试场景中可能有用,可以根据不同版本的比重来配置路由,或者将来自内部用户的流量定向到一组特定的实例。
使用VirtualService,可以为一个或多个主机名指定流量行为。在VirtualService中使用路由规则,告诉Envoy如何发送VirtualService的流量到适当的目标。路由目标可以是相同服务的不同版本,或者是完全不同的服务。
一个典型的应用场景是将流量发送到被指定为服务子集的服务的不同版本。客户端将 VirtualService 视为一个单一实体,将请求发送至 VirtualService 主机,然后 Envoy 根据 VirtualService 规则把流量路由到不同的版本中。例如, “20% 的调用转到新的版本” 或者 “这些用户的请求转到 v2 中”。这样,就可以方便您创建一种金丝雀的发布策略实现新版本流量的平滑比重升级。流量路由完全独立于实例部署,这意味着实现新版本服务的实例可以根据流量的负载来伸缩,完全不影响流量路由。相比之下,类似 Kubernetes 的容器调度平台仅支持基于部署中实例扩缩容比重的流量分发,那样会日趋复杂化。
VirtualService 也提供了如下功能:
1)通过单个 VirtualService 处理多个应用程序服务。例如,如果您的服务网格使用是 Kubernetes,您可以配置一个 VirtualService 来处理一个特定命名空间的所有服务。将单一的 VirtualService 映射为多个“真实”的服务特别有用,可以在不需要客户适应转换的情况下,将单体应用转换为微服务构建的复合应用系统。您的路由规则可以指定“请求到 monolith.com 的 URLs 跳转至 microservice A 中”。
2)和Gateway (网关) 一起配置流量规则来控制入口和出口流量。
在一些应用场景中,由于指定服务子集,需要配置 DestinationRule (目标规则) 来使用这些功能。在不同的对象中指定服务子集以及其他特定的目标策略可以在不同的VirtualService中清晰地复用这些功能。VirtualService 通过解耦客户端请求的目标地址和真实响应请求的目标工作负载为服务提供了合适的统一抽象层,而由此演化设计的配置模型为管理这方面提供了一致的环境。
示例:
下面的 VirtualService 根据是否来自于特定用户路由请求到不同的服务版本中(如果请求来自用户 jason