Agentgateway

With the retirement of ingress-nginx I've seen a lot of frustrations with Gateway API migrations due to differences in some of the resource models. The common problem is that Ingress users are often running self-service models, where application teams fully own their ingress configuration, including TLS certificates. This would look something like so: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: cert-manager.io/cluster-issuer: my-issuer name: app-a-routes namespace: app-a spec: rules: - host: app-a.example.com http: paths: - pathType: Prefix path: / backend: service: name: myservice port: number: 80 tls: - hosts: - app-a.example.com secretName: myingress-cert Combined with cert-manager a certificate would automatically be provisioned for app-a.example.com and linked up to the shared Nginx instance. DNS would then be handled with wildcard entries or external-dns. ...

When building out Agentgateway, we had a desire to introduce an embedded expression language to allow users to write custom logic to be evaluated at runtime. This is tremendously useful for a variety of use cases, such as: Extracting fields to log (request.headers["user-agent"]). Evaluating authorization conditions (jwt.sub == "admin" || request.path == "/public"). Manipulating fields in requests/responses (x-llm-model: 'json(request.body).model'). and so on. This provides a powerful way to allow users to customize behavior without needing custom compile-time extensions, external callouts, or complex YAML-based configuration. ...

While typical HTTP request routing happens based on the request headers/path, sometimes routing based on the body is useful. In particular, as AI use cases become more prevalent, the need to route based on the model field of the JSON request body is pretty handy to serve multiple models or route to different external LLMs. The Gateway API Inference Extension solution to this is to deploy an "external processor" that reads the body, and writes out a header; the header can then be matched as usual. An external processor is basically a service independent of the actual gateway proxy that processes the request. It does this by streaming the request headers/body between the proxy and the external processor. ...

I've spent the majority of my career building Istio's control plane, Istiod, with an emphasis on making it highly performant and scalable. And while it has come a very (very) long way, it's still a long way off from what a control plane could be. It's not alone. When I worked on building an open benchmark of Kubernetes Gateway control planes, I was surprised to find that no implementation met what I felt was a reasonable bar for a "highly scalable and performant control plane". ...