A Kubernetes-native API gateway, written in Rust.
An operator, control planes and data planes in one binary; Ingress and Gateway API served from the same data plane; cluster-wide rate limiting with no external store.
Status: the data plane runs; Kubernetes does not yet. The proxy serves traffic from a YAML file, the development harness; the control plane, the operator and the rate limiter are still to be built. Not for production. A hobby project with no timelines.
What it is for
One data plane for Ingress and Gateway API
Side by side, from ordinary Kubernetes objects. Ingress stays a first-class API.
Operator-driven
ControlPlane and DataPlane resources become Deployments
and Services; one control plane can drive many data planes, each its own failure
domain.
Cluster-wide rate limiting with no external store
Counters live in the data plane's memory and are shared between its pods peer to peer, off the request path, and limits keep working when the control plane is down.
Low added latency, measured
Thread-per-core on Tokio, our own HTTP/1 server and client, compiled filter chains, benchmarked beside NGINX, HAProxy, Envoy and Kong doing the same work on the same machine.
What works today
- Protocols: HTTP/1.1, HTTP/2 and HTTP/3 (QUIC) from clients; gRPC; WebSocket
- TLS on BoringSSL: certificates chosen by SNI, mTLS both ways
- Routing: Gateway API's matches and precedence; redirects, rewrites and mirrors
- Upstreams: load balancing, health checks, timeouts and retries
- L4: TCP and TLS passthrough, PROXY protocol
- Operations: Prometheus metrics, a drain on SIGTERM
Not yet: anything Kubernetes, rate limiting, access logs, authentication. The request path comes first, then rate limiting, then the control plane and the operator.
Get involved
- edgerush — the code, and a README that shows how to try it
- Contributing — contributions of any size are welcome, AI-assisted ones included
- Security — report problems privately
- hello@edgerush.dev — anything else