第三章 Istio 路由规则

目录

1、什么是路由规则

2、路由原理

3、如何配置路由

3.1 HTTP路由目标 （RouteDestination）

3.2 重定向（HTTPRedirect）

3.3 重写（HTTPRewrite）

3.4 重试（HTTPRetry）

3.5 流量镜像（Mirror）

3.6 故障注入（HTTPFaultInjection）

3.7 跨站（CorsPolicy）

---

1、什么是路由规则

Istio 的流量路由可让轻松控制服务之间的流量和API调用。Istio简化了断路器、超时和重试等服务级别属性的配置，并可以轻松设置重要任务，例如 A/B 测试、金丝雀发布和基于百分比的流量拆分的分阶段发布。它还提供开箱即用的可靠性功能，帮助您的应用程序更灵活地应对依赖服务或网络的故障。

Virtual Service 路由转发核心，主要是定义服务的路由规则，将满足规则的流量转发到对应服务后端项目，如果路由规则很多，可以对路由规则进行拆分（特点：一主多子）使用vs可以对 网关配置流量规则，控制进出流量。

Host 这是一个重要概念，区别Hosts，Host是外来流量调用目标服务使用时的地址，与虚拟服务的地址（Hosts）不同，目标地址必须是存在于 Istio 服务注册表中的真实地址，否则 Envoy 将不知道将流量发送到何处。这可以是网格服务，也可以是使用服务条目添加的非网格服务。一般情况默认为k8s的service地址，建议使用完全限定的地址，列：xxx-app.xxx-ns.svc.cluster.local。

2、路由原理

Istio 的流量管理模型依赖于与服务一起部署的sidecar。网格服务发送和接收的所有流量（数据平面流量）通过Envoy 代理，从而可以引导和控制网格周围的流量，而无需对服务进行任何更改。

Istio 使用 Envoy代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于调解服务网格中所有服务的所有入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。

Envoy 代理被部署为服务的 sidecar，在逻辑上使用 Envoy 的许多内置功能增强服务，例如：

• 动态服务发现
• 负载均衡
• TLS 终止
• HTTP/2 和 gRPC 代理
• 断路器
• 健康检查
• 基于百分比的流量拆分的分阶段部署
• 故障注入
• 丰富的指标

3、如何配置路由

HTTPRoute 规则十分灵活，可以执行转发、重定向（HTTPRedirect）、重写（HTTPRewrite）、重试（HTTPRetry）、故障注入（HTTPFaultInjection）、跨站（CorsPolicy）等策略

3.1 HTTP路由目标 （RouteDestination）

路由模版:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  gateways:
    - default/xxx-gateway
    - mesh
  hosts:
    - bookinfo.com
    - bookinfo.default.svc.cluster.local
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews.default.svc.cluster.local
  - match:
    - uri:
        prefix: /ratings
    route:
    - destination:
        host: ratings.default.svc.cluster.local
  - match:
    - uri:
        prefix: /info/
    rewrite:
        uri: /get/info/
    route:
    - destination:
        host: ratings-v2.default.svc.cluster.local
        port:
          number: 80

如上所示，路由规则是将特定流量子集路由到特定目的地的强大工具。可以对流量端口、标头字段、URI 等设置匹配条件。

gateways：应应用规则的网关的名称。VirtualService中  gateways（顶级字段）网关名称（如果有）。网关匹配独立于 sourceLabels。

特别注意：如果服务在网格内和网关上都需要访问，需要配置Gateway及保留关键字“mesh”

对于匹配条件，可以选择使用精确值、前缀或正则表达式来选择

匹配条件	类型	描述	必需的
exact	string	精确字符串匹配	不
prefix	string	基于前缀的匹配	不
regex	string	RE2 风格的基于正则表达式的匹配	不

还可以将多个匹配条件添加到同一个match块来满足需求，可以为任何给定的虚拟服务设置多个路由规则。可以在单个虚拟服务中使您的路由条件变得复杂或简单。

路由字段完整列表如下：

字段	类型	描述	必需的
name	string	为调试目的分配给路由的名称。路由的名称将与匹配的名称连接，并将记录在访问日志中以匹配此路由/匹配的请求。	不
match	HTTPMatchRequest[]	激活规则需要满足的匹配条件。单个匹配块内的所有条件都具有 AND 语义，而匹配块列表具有 OR 语义。如果任何一个匹配块成功，则匹配该规则。	不
route	HTTPRouteDestination[]	HTTP 规则可以重定向或转发（默认）流量。转发目标可以是服务的多个版本之一。与服务版本相关的权重决定了它接收的流量比例。	不
redirect	HTTPRedirect	HTTP 规则可以重定向或转发（默认）流量。如果在规则中指定了流量直通选项，则路由/重定向将被忽略。重定向原语可用于将 HTTP 301 重定向发送到不同的 URI 或授权。	不
delegate	Delegate	委托用于指定可用于定义委托 HTTPRoute 的特定 VirtualService。 Route只有当和为空时才可以设置Redirect，并且委托VirtualService的路由规则会与当前的路由规则合并。 注意： 仅支持一级委派。 delegate 的 HTTPMatchRequest 必须是 root 的严格子集，否则会发生冲突，HTTPRoute 不会生效。	不
rewrite	HTTPRewrite	重写 HTTP URI 和授权标头。Rewrite 不能与 Redirect 原语一起使用。转发前会进行重写。	不
timeout	Duration	HTTP 请求超时，默认禁用。	不
retries	HTTPRetry	HTTP 请求的重试策略。	不
fault	HTTPFaultInjection	故障注入策略应用于客户端的 HTTP 流量。请注意，在客户端启用故障时，将不会启用超时或重试。	不
mirror	Destination	除了将请求转发到预期目标之外，还将 HTTP 流量镜像到另一个目标。镜像流量是在尽力而为的基础上，边车/网关在从原始目的地返回响应之前不会等待镜像集群响应。将为镜像目的地生成统计信息。	不
mirrorPercentage	Percent	由mirror字段镜像的流量百分比。如果没有这个字段，所有的流量（100%）都会被镜像。最大值为 100。	不
corsPolicy	CorsPolicy	跨域资源共享策略 (CORS)。有关跨源资源共享的更多详细信息，请参阅 CORS 。	不
headers	Headers	标头操作规则	不

3.2 重定向（HTTPRedirect）

···
  - match:
    - uri:
        prefix: /info/
    redirect:
        uri: /get/info/
        authority: new-app
···

所有前缀为/info/请求都会被重定向到new-app 服务中的/get/info/地址

authority：替换url中Authority部分

3.3 重写（HTTPRewrite）

  - match:
    - uri:
        prefix: /info/
    rewrite:
        uri: /get/info/
    route:
    - destination:
        host: ratings-v2.default.svc.cluster.local
        port:
          number: 80

和HTTPRedirect规则稍有不同的是，HTTPRedirect是替换，HTTPRewrite可以重写前缀

3.4 重试（HTTPRetry）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
    retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: 5xx

reviews服务配置一个重试策略，在5xx条件下，最多3次重试，每次重试超时时间2s

重试条件如下：

• 5xx 如果上游服务器响应任何 5xx 响应代码，或者根本没有响应（断开/重置/读取超时），Envoy 将尝试重试。（包括连接失败和拒绝流）

• 网关错误  此策略类似于5xx策略，但只会重试导致 502、503 或 504 的请求。

• 重置  如果上游服务器根本没有响应（断开/重置/读取超时），Envoy 将尝试重试。

• 连接失败   如果由于与上游服务器的连接失败（连接超时等）而导致请求失败，Envoy 将尝试重试。（包含在5xx中）注意：连接失败/超时是 TCP 级别，而不是请求级别。这不包括通过 x-envoy-upstream-rq-timeout-ms或通过路由配置或通过 虚拟主机重试策略指定的上游请求超时。

• 特使限速 如果标头x-envoy-ratelimited存在，Envoy将重试。

• 可重试4xx 如果上游服务器使用可重试的4xx 响应代码进行响应，Envoy将尝试重试。目前，该类别中唯一的响应代码是 409。注意：请小心打开此重试类型。在某些情况下，409 可能表明需要更新乐观锁定修订版。因此，调用者不应该重试并且需要读取然后尝试另一次写入。如果在这种情况下发生重试，它总是会失败并返回另一个 409。

• 拒绝流 如果上游服务器使用 REFUSED_STREAM 错误代码重置流，Envoy 将尝试重试。此重置类型指示请求可以安全地重试。（包含在5xx中）

• 可重试状态码 如果上游服务器使用与重试策略 或x-envoy-retriable-status-codes标头中定义的响应代码匹配的任何响应代码进行响应，Envoy 将尝试重试。

• 可重试标头 如果上游服务器响应在重试策略或 x-envoy-retriable-header-names标头中包含任何匹配的标头，Envoy 将尝试重试 。

• http3-post-connect-failure 如果请求通过 HTTP/3 发送到上游服务器并在连接后失败，Envoy 将尝试重试。

  默认情况下，Envoy不会执行重试，除非您已按照上述方式进行了配置。

3.5 流量镜像（Mirror）

除了将请求转发到预期目标之外，还将 HTTP 流量镜像到另一个目标。镜像流量是在尽力而为的基础上，边车/网关在从原始目的地返回响应之前不会等待镜像集群响应。不会对生产系统产生影响。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
    - httpbin
  http:
  - route:
    - destination:
        host: httpbin
        subset: v1
      weight: 100
    mirror:
      host: httpbin
      subset: v2
    mirrorPercentage:
      value: 100.0

此路由规则将 100% 的流量发送到v1. 最后一节将 100% 的相同流量镜像发送到 httpbin:v2服务。当流量被镜像时，请求也被发送到镜像服务，其 Host/Authority 标头附加-shadow. 例如，cluster-1变成cluster-1-shadow。

3.6 故障注入（HTTPFaultInjection）

故障注入分为延迟故障注入和请求中止故障注入

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

例如，此虚拟服务对ratings服务的每 1000 个请求中的 1 个引入了 5 秒的延迟。

​虽然 Istio 故障恢复功能提高了网格中服务的可靠性和可用性，但应用程序必须处理故障或错误并采取适当的回退操作
 

3.7 跨站（CorsPolicy）

跨域资源共享( CORS ) 是一种基于HTTP标头的机制，它允许服务器指示除其自身之外的任何来源（域、方案或端口），浏览器应允许从中加载资源。CORS 还依赖于一种机制，浏览器通过该机制向托管跨域资源的服务器发出“预检”请求，以检查服务器是否允许实际请求。在该预检中，浏览器发送指示 HTTP 方法的标头和将在实际请求中使用的标头

跨域请求的一个示例：提供的前端 JavaScript 代码https://domain-a.com用于XMLHttpRequest对https://domain-b.com/data.json.

出于安全原因，浏览器限制从脚本发起的跨域 HTTP 请求。例如，XMLHttpRequestFetch API遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一来源请求资源，除非来自其他来源的响应包含正确的 CORS 标头。
 

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
  - ratings.prod.svc.cluster.local
  http:
  - route:
    - destination:
        host: ratings.prod.svc.cluster.local
        subset: v1
    corsPolicy:
      allowOrigins:
      - exact: https://example.com
      allowMethods:
      - POST
      - GET
      allowCredentials: false
      allowHeaders:
      - X-Foo-Bar
      maxAge: "24h"

例如，以上规则使用 HTTP POST/GET 将跨源请求限制为来自 example.com 域的请求，并将 Access-Control-Allow-Credentials标头设置为 false。此外，它只公开X-Foo-bar的 header ，并设置了 1 天的有效期。