跳至内容

HTTPRoute

从 v0.5.0 开始的标准频道

HTTPRoute 资源是 GA,并且自 v0.5.0 开始是标准频道的一部分。有关发布频道的更多信息,请参阅我们的 版本控制指南

HTTPRoute 是一个网关 API 类型,用于指定从网关侦听器到 API 对象(即服务)的 HTTP 请求的路由行为。

规范

HTTPRoute 的规范包括

  • ParentRefs- 定义此路由想要附加到的网关。
  • 主机名(可选)- 定义用于匹配 HTTP 请求的 Host 标头的主机名列表。
  • 规则- 定义对匹配的 HTTP 请求执行操作的规则列表。每个规则都包含 匹配过滤器(可选)、backendRefs(可选)和 超时(可选)字段。

以下是将所有流量发送到一个服务的 HTTPRoute 的示例:httproute-basic-example

附加到网关

每个路由都包含一种引用它想要附加到的父资源的方法。在大多数情况下,这将是网关,但这里有一些灵活性,允许实现支持其他类型的父资源。

以下示例显示路由将如何附加到 acme-lb 网关

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httproute-example
spec:
  parentRefs:
  - name: acme-lb

请注意,目标网关需要允许来自路由命名空间的 HTTPRoute 附加,才能使附加成功。

您还可以将路由附加到父资源的特定部分。例如,假设 acme-lb 网关包含以下侦听器

  listeners:
  - name: foo
    protocol: HTTP
    port: 8080
    ...
  - name: bar
    protocol: HTTP
    port: 8090
    ...
  - name: baz
    protocol: HTTP
    port: 8090
    ...

您可以使用 parentRefs 中的 sectionName 字段,仅将路由绑定到侦听器 foo

spec:
  parentRefs:
  - name: acme-lb
    sectionName: foo

或者,您也可以使用 parentRefs 中的 port 字段而不是 sectionName 来实现相同的效果

spec:
  parentRefs:
  - name: acme-lb
    port: 8080

绑定到端口还允许您一次附加到多个侦听器。例如,绑定到 acme-lb 网关的端口 8090 比按名称绑定到相应的侦听器更方便

spec:
  parentRefs:
  - name: acme-lb
    sectionName: bar
  - name: acme-lb
    sectionName: baz

但是,当按端口号绑定路由时,网关管理员将不再能够灵活地切换网关上的端口,而无需同时更新路由。此方法仅应在路由应应用于特定端口号(而不是端口可能更改的侦听器)时使用。

主机名

主机名定义用于匹配 HTTP 请求的 Host 标头的主机名列表。当发生匹配时,将选择 HTTPRoute 以根据规则和过滤器(可选)执行请求路由。主机名是网络主机的完全限定域名,如 RFC 3986 中所定义。请注意以下与 RFC 中定义的 URI 的“主机”部分的偏差

  • 不允许使用 IP 地址。
  • 不尊重 : 分隔符,因为不允许使用端口。

在评估 HTTPRoute 规则之前,会将传入请求与主机名进行匹配。如果未指定主机名,则将根据 HTTPRoute 规则和过滤器(可选)路由流量。

以下示例定义主机名 "my.example.com"

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httproute-example
spec:
  hostnames:
  - my.example.com

规则

规则定义根据条件匹配 HTTP 请求的语义,可选地执行额外的处理步骤,并可选地将请求转发到 API 对象。

匹配

匹配定义用于匹配 HTTP 请求的条件。每个匹配都是独立的,即如果满足任何一个匹配,则将匹配此规则。

以下匹配配置为例

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
...
spec:
  rules:
  - matches:
    - path:
        value: "/foo"
      headers:
      - name: "version"
        value: "2"
    - path:
        value: "/v2/foo"

要使请求与该规则匹配,它必须满足以下任一条件

  • 路径以 /foo 为前缀,并且包含标头 "version: 2"
  • 路径前缀为 /v2/foo

如果没有指定匹配项,则默认情况下为路径前缀匹配“/”,其效果是匹配每个 HTTP 请求。

过滤器(可选)

过滤器定义请求或响应生命周期中必须完成的处理步骤。过滤器充当扩展点,用于表达可能在网关实现中执行的额外处理。一些示例包括请求或响应修改、实施身份验证策略、速率限制和流量整形。

以下示例将标头 "my-header: foo" 添加到具有 Host 标头 "my.filter.com" 的 HTTP 请求中。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-filter-1
spec:
  hostnames:
    - my.filter.com
  rules:
    - filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: my-header
                value: foo
      backendRefs:
        - name: my-filter-svc1
          weight: 1
          port: 80

API 一致性是根据过滤器类型定义的。多个行为的排序效果目前未指定。这可能会在 alpha 阶段根据反馈而改变。

一致性级别由过滤器类型定义

  • 所有“核心”过滤器必须由实现支持。
  • 鼓励实施者支持“扩展”过滤器。
  • “特定于实现”的过滤器在不同实现之间没有 API 保证。

多次指定核心过滤器具有未指定或特定于实现的一致性。

所有过滤器都应该彼此兼容,除了 URLRewrite 和 RequestRedirect 过滤器,它们可能不能组合使用。如果实现无法支持过滤器的其他组合,则它们必须清楚地记录该限制。在指定不兼容或不支持的过滤器并导致 Accepted 条件设置为状态 False 的情况下,实现可以使用 IncompatibleFilters 原因来指定此配置错误。

BackendRefs(可选)

BackendRefs 定义应该将匹配请求发送到的 API 对象。如果未指定,则规则不会执行转发。如果未指定且未指定会产生响应的过滤器,则返回 404 错误代码。

以下示例将前缀为 /bar 的 HTTP 请求转发到端口为 8080 的服务 "my-service1",并将具有标头 magic: foo 的前缀为 /some/thing 的 HTTP 请求转发到端口为 8080 的服务 "my-service2"

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example
spec:
  controllerName: acme.io/gateway-controller
  parametersRef:
    name: example
    group: acme.io
    kind: Parameters
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: example
  listeners:  # Use GatewayClass defaults for listener definition.
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-app-1
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "foo.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: my-service1
      port: 8080
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /some/thing
      method: GET
    backendRefs:
    - name: my-service2
      port: 8080

以下示例使用 weight 字段将 90% 的前缀为 /foo 的 HTTP 请求转发到 "foo-v1" 服务,其余 10% 转发到 "foo-v2" 服务

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo-route
  labels:
    gateway: prod-web-gw
spec:
  hostnames:
  - foo.example.com
  rules:
  - backendRefs:
    - name: foo-v1
      port: 8080
      weight: 90
    - name: foo-v2
      port: 8080
      weight: 10

有关 weight 和其他字段的更多详细信息,请参阅 backendRef API 文档。

超时(可选)

自 v1.0.0 以来为实验性频道

HTTPRoute 超时自 v1.0.0 以来一直是实验性频道的组成部分。有关发布频道的更多信息,请参阅我们的 版本控制指南

HTTPRoute 规则包含 Timeouts 字段。如果未指定,则超时行为是特定于实现的。

HTTPRoute 规则中可以配置两种类型的超时

  1. request 是 Gateway API 实现向客户端 HTTP 请求发送响应的超时时间。此超时时间旨在涵盖尽可能接近整个请求-响应事务的时间,尽管实现可以 CHOOSE 在接收完整个请求流后才开始超时,而不是在客户端启动事务后立即开始。

  2. backendRequest 是 Gateway 向后端发送单个请求的超时时间。此超时时间涵盖从请求开始从 Gateway 发送到从后端接收完整响应的时间。如果 Gateway 尝试重新连接到后端,这将特别有用。

因为 request 超时包含 backendRequest 超时,所以 backendRequest 的值不能大于 request 超时的时间。

超时是可选的,它们的字段类型为 Duration。零值超时 ("0s") 必须被解释为禁用超时。有效非零值超时必须 >= 1ms。

以下示例使用 request 字段,如果客户端请求完成时间超过 10 秒,则会导致超时。该示例还定义了一个 2 秒的 backendRequest,它指定了从 Gateway 到后端服务 timeout-svc 的单个请求的超时时间

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: timeout-example
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /timeout
    timeouts:
      request: 10s
      backendRequest: 2s
    backendRefs:
    - name: timeout-svc
      port: 8080

有关更多详细信息,请参阅 timeouts API 文档。

后端协议
自 v1.0.0 以来为实验性频道

此概念自 v1.0.0 以来一直是实验性频道的组成部分。有关发布频道的更多信息,请参阅我们的 版本控制指南

某些实现可能需要明确标记 backendRef 以便使用特定协议路由流量。对于 Kubernetes 服务后端,可以通过指定 appProtocol 字段来实现这一点。

状态

Status 定义了 HTTPRoute 的观察状态。

RouteStatus

RouteStatus 定义了所有路由类型都需要观察到的状态。

父级

Parent 定义了与 HTTPRoute 关联的网关(或其他父资源)的列表,以及 HTTPRoute 相对于每个网关的状态。当 HTTPRoute 在 parentRefs 中添加对网关的引用时,管理网关的控制器应该在控制器第一次看到路由时在该列表中添加一个条目,并且应该在路由被修改时根据需要更新该条目。

以下示例表明 HTTPRoute "http-example" 已被命名空间 "gw-example-ns" 中的网关 "gw-example" 接受。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-example
...
status:
  parents:
  - parentRefs:
      name: gw-example
      namespace: gw-example-ns
    conditions:
    - type: Accepted
      status: "True"

合并

多个 HTTPRoute 可以附加到单个网关资源。重要的是,每个请求只能匹配一条路由规则。有关冲突解决如何应用于合并的更多信息,请参阅 API 规范