Routing

Route kinds, attachment, matching precedence, filters, and cross-namespace policies.

Route kinds

KindVersionTraffic
HTTPRoutev1HTTP/1.1 and HTTP/2, host + path + method + header + query matching
GRPCRoutev1gRPC with service/method and header matching, h2c to backends
TLSRoutev1SNI-routed TLS, passthrough or terminated
TCPRoutev1Raw TCP streams
UDPRoutev1UDP datagram flows

Backends are regular Services; krouter selects ready endpoints straight from EndpointSlices, so readiness changes take effect without restarts (see Pod readiness).

Attachment

Routes attach to Gateways through parentRefs:

  • sectionName pins one listener by name, port pins listeners by port (combined, both must match).
  • The Gateway side controls admission with allowedRoutes: namespaces (Same, All, or a label selector) and route kinds.
  • Every attachment decision is reported on the route’s status.parents with the standard conditions and reasons (Accepted, ResolvedRefs, NoMatchingParent, NotAllowedByListeners, …).

Matching precedence

HTTPRoute rules follow the upstream precedence exactly: most specific listener hostname, most specific route hostname, exact-over-prefix path (longest wins), method, most headers, most query parameters, then oldest route. Requests that match nothing get 404 (HTTP) or UNIMPLEMENTED (gRPC).

Filters

All Standard-channel filters are supported with upstream semantics:

  • RequestHeaderModifier / ResponseHeaderModifier: also per backendRefs[].filters, applied only to that backend’s share.
  • RequestRedirect: scheme, hostname, port, path, and status codes.
  • URLRewrite: hostname and path replacement.
  • RequestMirror: one or many mirrors, with percentage sampling.
  • CORS: preflights answered at the gateway, wildcard and credentialed origins handled per the Fetch specification.

Weighted backendRefs split traffic for canary-style rollouts, and rules[].timeouts enforces request and backend deadlines. A route using anything krouter does not support is rejected in full with UnsupportedValue (never partially applied).

Cross-namespace references

Any reference crossing a namespace boundary (route backends, listener certificates, CA bundles) requires a ReferenceGrant in the target namespace. This keeps namespace isolation under the control of the namespace owner, complementing Kubernetes multi-tenancy practices.

The multi-team tutorial walks through a complete setup.