[系统运维] 第三章 Istio 路由规则

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 系统运维 -> 第三章 Istio 路由规则 -> 正文阅读

[系统运维]第三章 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 天的有效期。