Istio从入门到精通—— 流量治理的原理 —— VirtualService（虚拟服务）
流量治理的原理 —— VirtualService（虚拟服务）
VirutalService 是 Istio 流量治理的一个核心配置，可以说是 Istio 流量治理中最重要的、最复杂的规则。
一、介绍概念
https://istio.io/latest/docs/reference/config/networking/virtual-service/
Configuration affecting traffic routing. Here are a few terms useful to define in the context of traffic routing.
影响流量路由的配置。下面是一些在流量路由上下文中有用的术语。
Service a unit of application behavior bound to a unique name in a service registry. Services consist of multiple network endpoints implemented by workload instances running on pods, containers, VMs etc.
服务是绑定到服务注册表中唯一名称的应用程序行为单元。服务由多个 network endpoints 组成，这些 endpoints 由运行在 Pod、containers、VMs等上的工作负载实例实现。
我理解的意思：这段话指的在分布式系统中，服务作为一种封装了特定应用行为的基本单元，通过注册到服务注册表并在网络上提供端点，使得其他服务可以发现并使用它。
Service versions (a.k.a. subsets) - In a continuous deployment scenario, for a given service, there can be distinct subsets of instances running different variants of the application binary. These variants are not necessarily different API versions. They could be iterative changes to the same service, deployed in different environments (prod, staging, dev, etc.). Common scenarios where this occurs include A/B testing, canary rollouts, etc. The choice of a particular version can be decided based on various criterion (headers, url, etc.) and/or by weights assigned to each version. Each service has a default version consisting of all its instances.
服务版本(又名子版本 )——在连续部署场景中，对于给定的服务，可以有不同的实例子版本运行应用程序二进制的不同变体。这些变体不一定是不同的 API 版本。它们可以是对相同服务的迭代更改，部署在不同的环境(prod、 staging、 dev 等)中。发生这种情况的常见场景包括 A/B 测试、金丝雀展示等。特定版本的选择可以根据不同的标准(header、 url 等)和/或赋予每个版本的权重来决定。每个服务都有一个由其所有实例组成的默认版本。
我理解的意思：在持续部署环境中，如何通过子集（不同版本的实例）进行服务的更新、测试和发布。不同的版本可以是同一服务的不同迭代，也可以是不同的API版本，根据不同的环境需求进行选择和部署。
Source： A downstream client calling a service.
Source 字段： 下游客户端调用服务。
Host： The address used by a client when attempting to connect to a service.
Host 字段： 客户端尝试连接服务时使用的地址。
Access model： Applications address only the destination service (Host) without knowledge of individual service versions (subsets). The actual choice of the version is determined by the proxy/sidecar, enabling the application code to decouple itself from the evolution of dependent services.
Access model： 应用程序仅针对目标 Service（Host）进行地址定位，而不了解单个服务版本（子版本）。版本的实际选择由 proxy/sidecar 确定，从而使应用程序代码能够从依赖服务的演变中解耦。
A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.
VirtualService 定义了一组流量路由规则，当 host 被寻址时，这些规则将被应用。 每个路由规则定义了特定协议流量的匹配标准。 如果流量匹配，则将其发送到注册表中定义的命名 destination service（或其子版本/版本）。
我理解的意思，VirtualService 是一种定义如何路由流量到某个主机的方法，它定义了一系列的路由规则，每个规则对应特定协议的流量。如果流量符合某个规则的条件，就会被路由到在注册表中定义的目标服务。
The source of traffic can also be matched in a routing rule. This allows routing to be customized for specific client contexts.
流量来源也可以在路由规则中进行匹配。这允许根据特定的客户端上下文定制路由。
我理解的意思，通过在路由规则中匹配流量源，可以根据不同的客户端上下文进行定制化的路由，以满足特定的需求，比如优化网络性能、保障特定用户的访问质量等。
The following example on Kubernetes, routes all HTTP traffic by default to pods of the reviews service with label “version: v1”. In addition, HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will be rewritten to /newcatalog and sent to pods with label “version: v2”.
以下是一个关于 Kubernetes 的例子，默认将所有 HTTP 流量路由到带有 “version: v1” 标签的评论服务 Pod。此外，以 /wpcatalog/ 或 /consumercatalog/ 开头的 HTTP 请求将被重写为 /newcatalog，并发送到带有 “version: v2” 标签的 Pod。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews.prod.svc.cluster.local
http:
- name: "reviews-v2-routes"
match:
- uri:
prefix: "/wpcatalog"
- uri:
prefix: "/consumercatalog"
rewrite:
uri: "/newcatalog"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v2
- name: "reviews-v1-route"
route:
- destination:
host: reviews.prod.svc.cluster.local
subset: v1
A subset/version of a route destination is identified with a reference to a named service subset which must be declared in a correspondingDestinationRule.
一个路由目的地的 subset/version 通过引用一个必须声明在相应 DestinationRule 中的命名服务子集来标识。
要识别路由目标的一个 subset/version，就需要引用这个已命名的服务子集。"a named service subset" 指的是这样一个已命名的服务子集，这个子集在对应的 DestinationRule 中被声明。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: reviews.prod.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
二、配置说明
注意：VirutalService 中的路由规则是一个数组，在应用时，只要匹配的第 1 个规则生效就跳出，不会检查后面的路由规则。
| 字段 | 类型 | 描述 | 是否必须 |
| host | string[] |
The destination hosts to which traffic is being sent. Could be a DNS name with wildcard prefix or an IP address. Depending on the platform, short-names can also be used instead of a FQDN (i.e. has no dots in the name). In such a scenario, the FQDN of the host would be derived based on the underlying platform. 正在发送流量目标主机。可以是带有通配符前缀的DNS名称或IP地址。根据平台的不同，也可以使用短名称代替完全限定域名（即名称中没有点）。在这种情况下，主机的完全限定域名将根据底层平台派生。 A single VirtualService can be used to describe all the traffic properties of the corresponding hosts, including those for multiple HTTP and TCP ports. Alternatively, the traffic properties of a host can be defined using more than one VirtualService, with certain caveats. Refer to the Operations Guide for details. 单个 VirtualService 可用于描述相应主机的所有流量属性，包括多个 HTTP 和 TCP 端口的流量属性。或者，可以使用多个VirtualService来定义主机的流量属性，但需要遵循某些注意事项。有关详细信息，请参阅Operations指南。 Note for Kubernetes users: When short names are used (e.g. “reviews” instead of “reviews.default.svc.cluster.local”), Istio will interpret the short name based on the namespace of the rule, not the service. A rule in the “default” namespace containing a host “reviews” will be interpreted as “reviews.default.svc.cluster.local”, irrespective of the actual namespace associated with the reviews service. To avoid potential misconfigurations, it is recommended to always use fully qualified domain names over short names. Kubernetes 用户注意事项：当使用短名称时（例如，“reviews” 而不是 “reviews.default.svc.cluster.local”），Istio 将根据规则的命名空间而不是服务的命名空间来解释短名称。在 “default” 命名空间中包含主机的规则将被解释为 “reviews.default.svc.cluster.local”，而不管与 reviews 服务关联的实际命名空间是什么。为了避免潜在的错误配置，建议始终使用全限定域名而不是短名称。 The hosts field applies to both HTTP and TCP services. Service inside the mesh, i.e., those found in the service registry, must always be referred to using their alphanumeric names. IP addresses are allowed only for services defined via the Gateway. hosts 字段适用于 HTTP 和 TCP 服务。网格内的服务，即在服务注册表中找到的服务，必须始终使用它们的字母数字名称进行引用。只有通过网关定义的服务才允许使用 IP 地址。 Note: It must be empty for a delegate VirtualService. 注意: 对于代理 VirtualService，它必须为空。 |
NO |
| gateways | string[] |
The names of gateways and sidecars that should apply these routes. Gateways in other namespaces may be referred to by 应用这些路由的网关和 sidecar 的名称。其他命名空间中的网关可以通过 <gateway namespace>/<gateway name> 引用，指定一个没有命名空间限定符的网关与指定 VirtualService 的命名空间相同。单个 VirtualService 用于网格中的 sidecar 以及一个或多个网关。此字段所施加的选择条件可以使用特定协议路由的匹配条件中的源字段来覆盖。保留字 mesh 用于暗示网格中的所有 sidecar。当省略此字段时，将使用默认网关（mesh），这将把规则应用于网格中的所有 sidecar。如果提供网关名称列表，规则将仅应用于网关。要将规则应用于网关和 sidecar，请指定 mesh 作为其中一个网关名称。 Istio 官网这里有点绕，我理解的意思，官网这里主要讨论了如何通过设置路由规则，将请求从网关路由到正确的 sidecar 服务上，并引出了2个概念，一个是gateways和sidecars。 首先，我们聊下 Gateways，Gateways：网关是服务网格中的入口点，通常用于处理进出网格的流量。它们可以被看作是进入和离开这个微服务网络的 "大门"。网关可以位于不同的命名空间中，可以通过 <gateway namespace>/<gateway name>的方式进行引用。 Sidecars： sidecar 是位于服务网格中的每个服务周围的代理，它们是服务的 "小伙伴"。它们帮助服务与其他服务进行通信，并处理进入和离开该服务的流量。 VirtualService：这是一个 Kubernetes 资源对象，用于定义路由规则。一个 VirtualService 可以被应用到 sidecars 或者 gateways 上。 mesh：这是一个保留字，用于表示所有的 sidecars。如果你在路由规则中使用了 mesh，那么这条规则将会应用到所有在网格中的 sidecars。 source：在协议特定的路由的匹配条件中，可以使用source字段来覆盖这个字段所设置的源选择条件。 To apply the rules to both gateways and sidecars, specify mesh as one of the gateway names.：如果想要将规则应用到gateways和sidecars上，可以将mesh作为一个gateway名称来指定。 场景1，服务只是在服务网格内部访问，这是最主要的使用场景。gateway 字段可以省略，实际上 VirtualService 的定义中无须出现这个字段。定义的规则作用到服务网格内部的 Sidecar。 场景2，服务只是在服务网格外部访问。其配置要关联的 Gateway，表示对应 Gateway 进来的流量执行在 VirutalService 上定义的流量规则。 场景3，在服务网格内部和服务网格外部都需要访问。这里呀给这个数组字段至少要配置两个元素，一个是外部访问的 "Gateway"，另外一个是 "mesh" 字段。 |
NO |
| http | HTTPRoute[] |
An ordered list of route rules for HTTP traffic. HTTP routes will be applied to platform service ports using HTTP/HTTP2/GRPC protocols, gateway ports with protocol HTTP/HTTP2/GRPC/TLS-terminated-HTTPS and service entry ports using HTTP/HTTP2/GRPC protocols. The first rule matching an incoming request is used. HTTP 通信路由规则的有序列表。HTTP 路由将应用于使用 HTTP/HTTP2/GRPC 协议的平台服务端口、使用 HTTP/HTTP2/GRPC/TLS 终止的 HTTPS 协议的网关端口和使用 HTTP/HTTP2/GRPC 协议的服务入口端口。使用与传入请求匹配的第一个规则。 |
NO |
| tls | TLSRoute[] |
An ordered list of route rule for non-terminated TLS & HTTPS traffic. Routing is typically performed using the SNI value presented by the ClientHello message. TLS routes will be applied to platform service ports named ‘https-’, ’tls-’, unterminated gateway ports using HTTPS/TLS protocols (i.e. with “passthrough” TLS mode) and service entry ports using HTTPS/TLS protocols. The first rule matching an incoming request is used. NOTE: Traffic ‘https-’ or ’tls-’ ports without associated virtual service will be treated as opaque TCP traffic. 非终止TLS和HTTPS流量的路由规则有序列表。路由通常通过客户端Hello消息中呈现的SNI值执行。TLS路由将应用于使用HTTPS/TLS协议（即使用“直通”TLS模式）的未终止网关端口，以及使用HTTPS/TLS协议的服务入口端口。匹配传入请求的第一个规则将被使用。注意：没有相关虚拟服务的'https-'或'tls-'流量端口将被视为不透明的TCP流量。 |
NO |
| tcp | TCPRoute[] | An ordered list of route rules for opaque TCP traffic. TCP routes will be applied to any port that is not a HTTP or TLS port. The first rule matching an incoming request is used.
针对不透明 TCP 通信的有序路由规则列表。TCP 路由将应用于任何不是 HTTP 或 TLS 端口的端口。使用与传入请求匹配的第一个规则。 |
NO |
| exportTo | string[] |
A list of namespaces to which this virtual service is exported. Exporting a virtual service allows it to be used by sidecars and gateways defined in other namespaces. This feature provides a mechanism for service owners and mesh administrators to control the visibility of virtual services across namespace boundaries. 此虚拟服务所导出到的命名空间的列表。导出虚拟服务使其可以被其他命名空间中定义的sidecar和网关使用。此功能为服务所有者和网格管理员提供了一种机制来控制虚拟服务在命名空间边界上的可见性。 If no namespaces are specified then the virtual service is exported to all namespaces by default. 如果没有指定命名空间，则虚拟服务默认导出到所有命名空间。 The value “.” is reserved and defines an export to the same namespace that the virtual service is declared in. Similarly the value “*” is reserved and defines an export to all namespaces. 值“.”是保留的，定义一个导出到虚拟服务声明所在的同一命名空间。同样，“*”是保留的值，并定义一个导出到所有命名空间。 |
NO |
三、VirtualService 配置模型
