Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
3.8 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress UDP Routers Documentation | UDP routers are responsible for connecting incoming UDP packets to the services that can handle them. Read the technical documentation. |
UDP Router
A UDP router is in charge of connecting incoming UDP packets to the services that can handle them. Unlike HTTP and TCP routers, UDP routers operate at the transport layer and have unique characteristics due to the connectionless nature of UDP.
!!! important "UDP Router Characteristics" - UDP is connectionless, so there is no concept of a request URL path or Host SNI to match against - UDP routers are essentially load-balancers that distribute packets to backend services - UDP routers can only target UDP services (not HTTP or TCP services) - Sessions are tracked with configurable timeouts to maintain state between client and backend
Configuration Example
udp:
routers:
my-udp-router:
entryPoints:
- "udp-ep"
- "dns"
service: my-udp-service
[udp.routers]
[udp.routers.my-udp-router]
entryPoints = ["udp-ep", "dns"]
service = "my-udp-service"
labels:
- "ingress.udp.routers.my-udp-router.entrypoints=udp-ep,dns"
- "ingress.udp.routers.my-udp-router.service=my-udp-service"
{
"Tags": [
"ingress.udp.routers.my-udp-router.entrypoints=udp-ep,dns",
"ingress.udp.routers.my-udp-router.service=my-udp-service"
]
}
Configuration Options
| Field | Description | Default | Required |
|---|---|---|---|
entryPoints |
The list of entry points to which the router is attached. If not specified, UDP routers are attached to all UDP entry points. | All UDP entry points | No |
service |
The name of the service that will handle the matched UDP packets. UDP services are typically load balancer services that distribute packets to multiple backend servers. See UDP Service for details. | Yes |
Sessions and Timeout
Even though UDP is connectionless, Hanzo Ingress's UDP router implementation relies on sessions to maintain state about ongoing communication between clients and backends. This allows the proxy to know where to forward response packets from backends.
Each session has an associated timeout that cleans up inactive sessions after a specified duration of inactivity.
Session timeout can be configured using the entryPoints.name.udp.timeout option in the static configuration. See EntryPoints documentation for details.
Router Naming
- The character
@is not authorized in the router name - Router names should be descriptive and follow your naming conventions
- In provider-specific configurations (Docker, Kubernetes), router names are often auto-generated based on service names