Istio从入门到精通—— 流量治理的原理 —— VirutalService —— HTTPMatchRequest

流量治理的原理 —— VirutalService —— HTTPMatchRequest

https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMatchRequest

HttpMatchRequest specifies a set of criterion to be met in order for the rule to be applied to the HTTP request. For example, the following restricts the rule to match only requests where the URL path starts with /ratings/v2/ and the request contains a custom end-user header with value jason.

描述了匹配条件和操作以路由未终止的 TLS 流量（TLS/HTTPS）。以下路由规则将基于 SNI 值将到达名为 "mygateway" 网关端口 443 的未终止的 TLS 流量转发到网格中的内部服务。

我的理解是："The following routing rule forwards unterminated TLS traffic arriving at port 443 of gateway called “mygateway” to internal services in the mesh based on the SNI value."：这是主要的路由规则描述。这里的 "unterminated TLS traffic" 指的是到达 443 端口的未终止的 TLS 或 HTTPS 流量。"mygateway" 则是指一个名为 "mygateway" 的网关。根据 SNI（服务器名称指示）的值，这个路由规则将把到达这个网关的未终止的 TLS 流量转发到服务网格中的内部服务。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings-route
spec:
  hosts:
  - ratings.prod.svc.cluster.local
  http:
  - match:
    - headers:
        end-user:
          exact: jason
      uri:
        prefix: "/ratings/v2/"
      ignoreUriCase: true
    route:
    - destination:
        host: ratings.prod.svc.cluster.local

HTTPMatchRequest CANNOT be empty.Note:

HTTPMatchRequest 不能为空。注意:

我的理解是：指出 HTTPMatchRequest 不能为空。HTTPMatchRequest 是Istio VirtualService 中用于匹配 HTTP 请求的条件，包括 URI、header、方法等。如果 HTTPMatchRequest 为空，Istio 将无法根据请求的属性进行路由，因此这是不允许的。

  1. If a root VirtualService have matched any property (path, header etc.) by regex, delegate VirtualServices should not have any other matches on the same property. 如果根 VirtualService 通过正则表达式匹配了任何属性(path, header 等) ，则委托 VirtualServices 不应该在同一属性上有任何其他匹配。 我的理解是：当 root VirtualService 已经使用正则表达式匹配了请求的某个属性（path, header etc.）时，delegate([ˈdεləˌget]) VirtualServices 就不应该再尝试匹配相同的属性。原因是 Istio 在处理请求时会按照特定的顺序评估 VirtualService，如果一个请求已经被 root VirtualService 匹配，那么它就不会再被 delegate VirtualServices 评估。因此，如果 delegate VirtualServices 尝试匹配与根 VirtualService 相同的属性，这些规则将不会被执行。
  2. If a delegate VirtualService have matched any property (path, header etc.) by regex, root VirtualServices should not have any other matches on the same property. 如果委托 VirtualService 通过正则表达式匹配了任何属性(path, header 等) ，则 root VirtualServices 不应该在同一属性上有任何其他匹配。 我的理解是：这个和上面的相反，当 delegate VirtualService 已经匹配了某个属性时，root VirtualService 不应该再尝试匹配相同的属性。原因同样是 Istio 处理请求的顺序和规则。如果一个请求已经被 delegate VirtualService 匹配并处理，那么 root VirtualService 中的相关规则将不会被执行。
Field Type Description Required
name string The name assigned to a match. The match’s name will be concatenated with the parent route’s name and will be logged in the access logs for requests matching this route. 分配给 match 的名称。match 的名称将与父路由的名称连接，并将在与该路由匹配的请求的访问日志中记录。 No
uri StringMatch

URI to match values are case-sensitive and formatted as follows:

匹配值的 URI 区分大小写，格式如下：

    • exact: "value" for exact string match

      "value" 表示精确的字符串匹配

    • prefix: "value" for prefix-based match

      prefix: "value" 用于基于前缀的匹配

    • regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax). regex: RE2 风格基于 regex 匹配的 "value" (https://github.com/google/RE2/wiki/syntax)。

Note: Case-insensitive matching could be enabled via the ignore_uri_case flag. 注意: 不区分大小写的匹配可以通过忽略 ignore_uri_case 标志来启用。

No
scheme StringMatch

URI Scheme values are case-sensitive and formatted as follows:

URI Scheme 值区分大小写，格式如下:

    • exact: "value" for exact string match

      prefix: "value" 用于基于前缀的匹配

    • prefix: "value" for prefix-based match

      "value" 表示精确的字符串匹配

regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

regex: RE2 风格基于 regex 匹配的 "value" (https://github.com/google/RE2/wiki/syntax)。

No
method StringMatch 

HTTP Method values are case-sensitive and formatted as follows:

HTTP 方法值是区分大小写的，并按以下格式进行格式化：

    • exact: "value" for exact string match
    • prefix: "value" for prefix-based match

regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

Regex: RE2 风格基于 regex 匹配的 "值"( https://github.com/google/RE2/wiki/syntax )。

No
authority StringMatch

HTTP Authority values are case-sensitive and formatted as follows:

HTTP授权值是区分大小写的，格式如下：

    • exact: "value" for exact string match
    • prefix: "value" for prefix-based match

regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

Regex: RE2 风格基于 regex 匹配的 "值" ( https://github.com/google/RE2/wiki/syntax )。

No
headers map<string,StringMatch>

The header keys must be lowercase and use hyphen as the separator, e.g. x-request-id.

标题键必须为小写，并使用连字符作为分隔符，例如 x-request-id。

Header values are case-sensitive and formatted as follows:

标题值是区分大小写的，格式如下：

    • exact: "value" for exact string match
    • prefix: "value" for prefix-based match

    • regex: "value" for RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

      Regex: RE2 风格基于 regex 匹配的 "值" ( https://github.com/google/RE2/wiki/syntax )。

If the value is empty and only the name of header is specified, presence of the header is checked. To provide an empty value, use {}, for example:

如果值是空的，并且只指定了标题的名称，则检查标题是否存在。要提供一个空值，请使用{}，例如： 

 - match:
   - headers:
       myheader: {}

Note: The keys uri, scheme, method, and authority will be ignored.

注意：将忽略键uri、scheme、method 和 authority。

No
port uint32

Specifies the ports on the host that is being addressed. Many services only expose a single port or label ports with the protocols they support, in these cases it is not required to explicitly select the port.

指定正在被寻址的主机上的端口。许多服务只暴露单个端口或使用它们支持的协议对端口进行标记，在这些情况下，不需要显式选择端口。

No
sourceLabels

map<string,string>

One or more labels that constrain the applicability of a rule to source (client) workloads with the given labels. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

一个或多个标签，用于限制规则对具有给定标签的源（client）工作负载的适用性。如果 VirtualService 在顶级 gateway 字段中指定了网关列表，则必须包含此字段适用的保留网关网格。

我理解的意思是：这是关于 Istio 服务网格中 VirtualService 的配置描述，特别是其中 HTTPMatchRequest 中的 sourceLabels 字段。

"One or more labels that constrain the applicability of a rule to source (client) workloads with the given labels." sourceLabels 字段允许你定义一个或多个标签，这些标签用于约束规则只适用于具有给定标签的源（client）工作负载。 换句话说，你可以使用这些标签来指定哪些工作负载（或服务）可以触发特定的路由规则。

"If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable." 如果 VirtualService 在其顶级 gateways 字段中指定了一系列的网关，那么为了使 sourceLabels 字段有效，这个列表必须包含保留的网关 mesh。mesh 网关代表 Istio 服务网格中的所有工作负载，它是一个特殊的网关，用于标识网格内部的所有服务间的通信。因此，如果 VirtualService 定义了特定的网关，但仍然希望 sourceLabels 对整个网格中的工作负载有效，那么必须在网关列表中包括 mesh。

sourceLabels 允许你精确地控制哪些源工作负载可以触发 VirtualService 中定义的路由规则，而 gateways 字段和 mesh 网关的使用则进一步限定了这些规则在哪些网关或网格部分中有效。这些功能共同为 Istio 提供了强大而灵活的流量管理能力。

No
gateways string[]

Names of gateways where the rule should be applied. Gateway names in the top-level gateways field of the VirtualService (if any) are overridden. The gateway match is independent of sourceLabels.

应该应用规则的网关名称。VirtualService (如果有的话) 顶级网关字段中的网关名称将被覆盖。网关匹配与 sourceLabels 无关。

"Names of gateways where the rule should be applied." gateways 字段允许你指定应用该规则的网关的名称。在 Istio 中，网关通常是处理入站和出站流量的边缘服务，可以作为服务网格的入口和出口。通过在 VirtualService 中定义 gateways，你可以控制哪些网关应该应用这个特定的路由规则。

"Gateway names in the top-level gateways field of the VirtualService (if any) are overridden." 如果在 VirtualService 的顶级字段中已经定义了 gateways，那么在 HTTPMatchRequest 中的 gateways 将会覆盖顶级字段中的定义。这意味着更具体的路由规则（在 HTTPMatchRequest 级别定义的）可以覆盖更一般的规则（在 VirtualService 顶级字段中定义的）。这为用户提供了灵活性，可以根据需要调整路由规则的应用范围。

"The gateway match is independent of sourceLabels." 网关匹配与源标签（sourceLabels）是独立的。即使一个请求来自具有特定 sourceLabels 的工作负载，gateways 字段也会单独地确定是否应用该规则。这表明 gateways 和 sourceLabels 是两个独立的匹配条件，它们各自影响路由规则的应用。

gateways 字段在 Istio 的 VirtualService 中允许用户精确地指定哪些网关应该应用特定的路由规则。通过在 HTTPMatchRequest 中包含或覆盖这些定义，用户可以在不同的级别上控制流量路由的行为。此外，gateways 的匹配是独立于 sourceLabels 的，这提供了额外的灵活性和控制粒度，使用户能够根据需要精确地管理流量路由。

No
queryParams map<string,StringMatch>

Query parameters for matching.

匹配的查询参数。

Ex:

    • For a query parameter like “?key=true”, the map key would be “key” and the string match could be defined as exact: "true".

      对于像 "?key=true" 这样的查询参数，map 的键将是 "key"，字符串匹配可以定义为精确："true"。

    • For a query parameter like “?key”, the map key would be “key” and the string match could be defined as exact: "".

      对于像 "?key" 这样的查询参数，map的键将是 "key"，字符串匹配可以定义为精确的：""。

    • For a query parameter like “?key=abc” or “?key=abx”, the map key would be “key” and the string match could be defined as prefix: "ab".

      对于像“?key=abc”或“?key=abx”这样的查询参数，映射键将是“key”，字符串匹配可以定义为前缀：“ab”。

    • For a query parameter like “?key=123”, the map key would be “key” and the string match could be defined as regex: "\d+$". Note that this configuration will only match values like “123” but not “a123” or “123a”.

      对于像“?key=123”这样的查询参数，map的键是“key”，字符串匹配可以定义为正则表达式："\d+$"。请注意，此配置只匹配像“123”这样的值，而不匹配“a123”或“123a”。

No
ignoreUriCase bool

Flag to specify whether the URI matching should be case-insensitive.
Note: The case will be ignored only in the case of exact and prefix URI matches.

flag 用于指定 URI 匹配是否应为大小写不敏感。注意：只有在精确和前缀 URI 匹配的情况下才会忽略大小写。

No
withoutHeaders map<string,StringMatch>

withoutHeader has the same syntax with the header, but has opposite meaning. If a header is matched with a matching rule among withoutHeader, the traffic becomes not matched one.

withoutHeader 与 header 具有相同的语法，但具有相反的含义。如果 header 与 withoutHeader 中的匹配规则匹配，则流量将变为不匹配的流量。

No
sourceNamespace string Source namespace constraining the applicability of a rule to workloads in that namespace. If the VirtualService has a list of gateways specified in the top-level gateways field, it must include the reserved gateway mesh for this field to be applicable.

Source namespace 限制规则在该 namespace 中工作负载的适用性。如果 VirtualService 在顶级 gateway 字段中指定了 gateway 列表，则必须包括为该字段保留的 gateway mesh，才能使该规则适用。

No
statPrefix string The human readable prefix to use when emitting statistics for this route. The statistics are generated with prefix route.<stat_prefix>. This should be set for highly critical routes that one wishes to get “per-route” statistics on. This prefix is only for proxy-level statistics (envoy_) and not service-level (istio_) statistics. Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix for statistics that are generated when this is configured.

当为该路由生成统计信息时使用的人类可读前缀。使用前缀 route.<stat_prefix>. 生成统计信息。对于希望获得 “按路由” 统计信息的高度关键路由，应设置此前缀。此前缀仅适用于代理级别统计信息（envoy_），而不适用于服务级别（istio_）统计信息。有关配置此项时生成的统计信息，请参阅 https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-stat-prefix。

关于Envoy代理的路由统计前缀的设置。

1. 人类可读的名称前缀：当为这个路由生成统计数据时，我们会使用一个名称前缀。这个前缀是为了让人们更容易理解或识别这些统计数据。

2.生成的统计数据：使用上述的名称前缀，我们可以为路由生成统计数据。这些统计数据以 “route.<stat_prefix>.” 的形式出现。例如，如果 stat_prefix 设置为 "myroute"，则统计数据的名称可能是"route.myroute.some_stat"。

3.设置的目的：这个前缀应该为那些你希望获得“按路由”统计数据的关键路由设置。这意味着，如果你有多个路由，并希望为每个路由单独收集统计数据，那么每个路由都会有不同的前缀，这使得你可以区分哪个统计数据来自哪个路由。

4.只针对代理级别的统计数据：此前缀仅适用于Envoy代理级别的统计数据，而不是服务级别的统计数据（Istio的统计数据）。这意味着，如果你在Envoy代理上配置了这个前缀，那么你将在Envoy的监控系统中看到相关的统计数据，但这些数据不会出现在Istio的控制平面或其他Istio服务中。

5. 相关的文档：最后提到的 URL 指向了 Envoy 的 API 文档，其中详细描述了当配置此选项时会生成哪些统计数据。

No
posted @ 2023-12-12 14:02  左扬  阅读(93)  评论(0)  编辑  收藏  举报
levels of contents