sigs.k8s.io/gateway-api@v1.0.0/site-src/guides/http-routing.md (about)

     1  # HTTP routing
     2  
     3  The [HTTPRoute resource](/api-types/httproute) allows you to match on HTTP traffic and
     4  direct it to Kubernetes backends. This guide shows how the HTTPRoute matches
     5  traffic on host, header, and path fields and forwards it to different
     6  Kubernetes Services.
     7  
     8  The following diagram describes a required traffic flow across three different
     9  Services:
    10  
    11  - Traffic to `foo.example.com/login` is forwarded to `foo-svc`
    12  - Traffic to `bar.example.com/*` with a `env: canary` header is forwarded
    13  to `bar-svc-canary`
    14  - Traffic to `bar.example.com/*` without the header is forwarded to `bar-svc`
    15  
    16  ![HTTP Routing](/images/http-routing.png)
    17  
    18  The dotted lines show the Gateway resources deployed to configure this routing
    19  behavior. There are two HTTPRoute resources that create routing rules on the
    20  same `prod-web` Gateway. This illustrates how more than one Route can bind to a
    21  Gateway which allows Routes to merge on a Gateway as long as they don't
    22  conflict. For more information on Route merging, refer to the [HTTPRoute
    23  documentation](/api-types/httproute#merging).
    24  
    25  In order to receive traffic from a [Gateway][gateway] an `HTTPRoute` resource
    26  must be configured with `ParentRefs` which reference the parent gateway(s) that it
    27  should be attached to. The following example shows how the combination
    28  of `Gateway` and `HTTPRoute` would be configured to serve HTTP traffic:
    29  
    30  ```yaml
    31  {% include 'standard/http-routing/gateway.yaml' %}
    32  ```
    33  
    34  An HTTPRoute can match against a [single set of hostnames][spec].
    35  These hostnames are matched before any other matching within the HTTPRoute takes
    36  place. Since `foo.example.com` and `bar.example.com` are separate hosts with
    37  different routing requirements, each is deployed as its own HTTPRoute -
    38  `foo-route` and `bar-route`.
    39  
    40  The following `foo-route` will match any traffic for `foo.example.com` and apply
    41  its routing rules to forward the traffic to the correct backend. Since there is
    42  only one match specified, only `foo.example.com/login/*` traffic will be
    43  forwarded. Traffic to any other paths that do not begin with `/login` will not
    44  be matched by this Route.
    45  
    46  ```yaml
    47  {% include 'standard/http-routing/foo-httproute.yaml' %}
    48  ```
    49  
    50  Similarly, the `bar-route` HTTPRoute matches traffic for `bar.example.com`. All
    51  traffic for this hostname will be evaluated against the routing rules. The most
    52  specific match will take precedence which means that any traffic with the `env:
    53  canary` header will be forwarded to `bar-svc-canary` and if the header is
    54  missing or not `canary` then it'll be forwarded to `bar-svc`.
    55  
    56  ```yaml
    57  {% include 'standard/http-routing/bar-httproute.yaml' %}
    58  ```
    59  
    60  [gateway]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Gateway
    61  [spec]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec
    62  [svc]:https://kubernetes.io/docs/concepts/services-networking/service/