liveBook · Manning

Backendrefs field

As explained in Kubernetes in Action, Second Edition

A backend reference is an HTTPRoute field entry that identifies a service or other backend to which matching traffic is forwarded.

The `backendRefs` field tells an HTTPRoute rule where to forward matching HTTP requests. A simple entry names a Kubernetes Service and its port. The route attaches to a Gateway through `parentRefs`; the backend reference identifies the destination behind that gateway. section 13.3.1

Listing 13.2 Attaching an HTTP Service to a Gateway using an HTTPRoute object
apiVersion: gateway.networking.k8s.io/v1      #1
kind: HTTPRoute                       #1       
metadata:
  name: kiada     #2
spec:
  parentRefs:            #3
  - name: kiada          #3
  hostnames:                #4
  - kiada.example.com       #4
  rules:                  #5
  - backendRefs:          #5
    - name: kiada         #5
      port: 80            #5

This minimal route attaches to a gateway, accepts requests for `kiada.example.com`, and forwards them to port 80 of the `kiada` Service. section 13.3.1

A backend reference can include `group` and `kind`. For an ordinary Service, these resolve to the core Kubernetes API group (shown as an empty string) and `Service`. Inspecting an applied route with `kubectl get httproute kiada -o yaml` shows these values and the default `weight: 1`. The route’s `ResolvedRefs` status condition reports whether its references could be resolved. section 13.3.1

Listing 13.3 Splitting HTTP traffic using weights
spec:
  rules:
  - backendRefs:           #1
    - name: kiada-stable     #2
      port: 80               #2
      weight: 9              #2
    - name: kiada-new     #3
      port: 80            #3
      weight: 1           #3

List two Services under one rule to split requests: weights of 9 and 1 send approximately nine-tenths to the stable Service and one-tenth to the new Service. Without weights, listed backends share traffic evenly. section 13.3.2

Different rules can instead send different requests to different backends. For example, a rule matching `POST` can forward to a new Service, while a rule without match conditions catches other requests and forwards them to a stable Service. Rules can also match headers, paths, or query parameters. section 13.3.3

Do not confuse a rule’s destination with every backend mentioned in a filter. A `RequestMirror` filter copies a request to another backend, but the client receives the response from the rule’s `backendRefs` destination. A `RequestRedirect` rule needs no `backendRefs` because the gateway redirects rather than forwards the request. section 13.3.4

How Kubernetes in Action, Second Edition covers it

How deep it goes
Works through Service references, default fields, weights, and routing rules; does not descend into gateway-controller implementation.
Examples
Uses a single-Service route, a 9:1 stable/new split, and method-based routing with a catch-all rule.
What it assumes
Introduces the reference through a basic HTTPRoute manifest while relying on a Gateway and Service as the objects being connected.
What you can do after
Operate/configure it to forward requests to a Service, divide traffic between Services, or select backends using request matches.
How it connects
Connects HTTPRoute rules to Kubernetes Services, Gateways, request matching, traffic splitting, and request-mirroring filters.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.