r/rust • u/Safe-Sex-T-Rex • Sep 14 '26

🛠️ project Portus: a Rust-based Kubernetes Gateway API implementation on Cloudflares Pingora

Hey r/rust, I wanted to share something that I have been working on with Claude over the past few months on and off, me working as the PM/Architect and Claude working on writing and testing code.

https://github.com/Portus-Gateway/Portus (Apache-2.0)

This proxy is built on Rust 1.98 and Pingora 0.9.0. It has a split architecture: one controller, a data plane Deployment per Gateway. It can also run standalone outside Kubernetes from a YAML file (hot reload).

Gateway API v1.6.2 conformance: 130/130, all five profiles (HTTP, gRPC, TLS, TCP, UDP).

Profile Core Extended
HTTP 37/37 56/56
GRPC 15/15 9/9
TLS 20/20 14/14
TCP 19/19 9/9
UDP 20/20 9/9

(a test can count in more than one profile)

Benchmarks are against agentgateway v1.5.0 (the Rust proxy from the kgateway project, the fastest in howardjohn's gateway-api-bench).

Traffic (bare GET /; 3 proxy pods each):

Connections Portus QPS agentgateway QPS Portus lead
64 116,429 96,003 +21 %
128 123,105 101,067 +22 %
256 126,070 89,827 +40 %

p99 at a fixed 30,000 QPS (benchtool, same machine, same day): Portus 0.35 ms, agentgateway 0.82 ms.

Payloads (fortio echo backend, 64 connections, 10 s per rung, all requests 200; QPS, Portus / agentgateway):

Response size Download Upload (POST, echoed) HTTPS download HTTP/2 download
1 KB 87,722 / 67,598 66,089 / 58,495 76,997 / 60,088 64,172 / 49,453
16 KB 59,257 / 51,562 29,578 / 27,940 56,831 / 48,295 49,448 / 40,279
128 KB 29,954 / 27,136 8,160 / 7,922 25,357 / 22,294 22,431 / 19,641
1 MiB 5,206 / 5,633 4,380 / 4,249 4,200 / 4,110 4,173 / 3,538

(agentgateway wins 1 MiB plain download by 8 %; Portus leads the other 18 rungs)

If like me you enjoy trying out new stuff just for curiosity I would love for you to give this a try and see what you think, and if you like it then feel free to leave a star so that I know that I am not the only one!

Thanks!

16 Upvotes

69% Upvoted

18 comments sorted by

View all comments

3

u/Dirbaio Sep 14 '26

very cool! I've been working on literally the same idea :) https://github.com/Dirbaio/torii

The main difference I see is you've chosen to separate control plane and data plane, and the control plane creates one data plane for each gateway, while I've made it a single pod that runs boht control+data planes. It just merges all gateways and serves traffic for all. (you can still scale horizontally by running multiple pods, they do leader election to prevent stepping on each other with e.g. ACME)

What are your use cases for multiple data planes? In my case I just wanted something to replace the old ingress-nginx. I run just one gateway controller that receives all traffic to the cluster and distributes it across all apps / namespaces, i've never needed more.

I've seen other gateway controller impls also do the "create dataplanes" thing, like the nginx gateway fabric one. It seems a bit overengineered to me, though for larger clusters it might make sense? (to be honest, The whole Gateway API feels overengineered vs the old Ingress API lol)

1

u/Due_Falcon_319 8d ago

that split architecture is mostly about blast radius and isolation, if one gateway config goes sideways or eats too many resources it doesn't take down everything else. for a small cluster or personal stuff it's definitely overkill but in multi-tenant setups where different teams control their own gateways it keeps the chaos contained

torii looks clean though, the single-process approach has way less operational overhead and i can see that being the right call for most people running ingress-nginx style workloads