第三章 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/v1alpha3kind: VirtualServicemetadata:  name: bookinfospec:  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”

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

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

路由字段完整列表如下：

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/v1alpha3kind: VirtualServicemetadata:  name: reviewsspec:  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/v1alpha3kind: VirtualServicemetadata:  name: httpbinspec:  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/v1alpha3kind: VirtualServicemetadata:  name: ratingsspec:  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/v1alpha3kind: VirtualServicemetadata:  name: ratings-routespec:  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 天的有效期。