Kubernetes releases ingress2gateway tool for upcoming GA of Gateway API (opens in new tab)

My team at Kong would agree - as maintainers of a very feature-rich implementation of Ingress we've felt the pain of pushing Ingress to the limits of its expressive power (hence our current strong focus on Gateway API).

The Ingress API is fine as long as you're in the "basic proxying with simple path-based routing" territory, but once you want to do something more serious (route by query string, configure weighted load balancing, work with TLS, deal with methods, etc - let alone other protocols than HTTP) you're kinda stuck with vendor-specific extensions that mostly rely on annotations.

Kong has an implementation of Gateway API for HTTP(S), TCP, UDP, TLS, gRPC that aims to offer a fairly smooth transition from Ingress to Gateway API by supporting both in our Kong Ingress Controller and working on conversion tooling (we're the only provider other than nginx currently available in the ingress2gateway tool). We strongly believe that (at least Kong's implementation of) Gateway API will be much easier to use than Ingress.

You can try out Kong's (certified conformant with Gateway API "core" profile) beta implementation by following [1] for HTTP. There's a guide for gRPC as well, among others [2]. As Kong's implementation of Gateway API [3] is nearing general availability, we're very open to community feedback.

[1] https://docs.konghq.com/kubernetes-ingress-controller/2.12.x...

[2] https://docs.konghq.com/kubernetes-ingress-controller/2.12.x...

[3] https://github.com/Kong/kubernetes-ingress-controller

Ingress seems to make easy things hard. I’ve spent hours dicking around with its config in some deployments, when I could have done the same thing in vanilla nginx in like 10 minutes.

Especially with some vendor helm charts, it’s often a nightmare if you’re deviating from the base config.

Having looked at some Gateway configs, I wouldn't say simplify. It looks painfully verbose, but at least more things should be possible without resorting to hacky annotations for everything.

Istio kind of sucks TBH from the architecture astronauts getting high on their own supply. It reminds me of the worst excesses of OOP abstraction. The sort of code that you want to burn down to the ground after hitting your head against it for a few days.

The Gateway API is a relatively straightforward implementation of "north-south" traffic and doesn't try to handle "east-west" traffic, limiting its complexity. Its existence means I can use something more sane like Contour, but it's built on common resources that Istio can understand nicely as well, if need be. So the overall advantage is that you can hop between implementations without having to relearn everything from scratch.

My biggest frustration with the Gateway API is actually how extensions are developed: the spec just doesn't (or didn't last time I looked) touch timeouts other than just saying "implementation defined" because of the different ways that's handled currently. To create extensions, just define your own custom resource that does whatever you want not currently covered by the spec.

Istio and other popular tools has implemented its own gateway APIs because of the limits of Ingress API.

So the the new Gateway API seem to support more use cases so the user can use a more portable API.

Istio and many other tools already supports this: https://gateway-api.sigs.k8s.io/implementations/#implementat...

The Gateway spec itself supports both v4 and v6 addresses: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.netw...

More importantly you will want to check your specific Gateway implementation for support.

cilium gateway for UDP is still WIP but that's because of the cni implementation not the spec. they do not differentiate data streams so they can't use 2 gateways on the same port for TCP and UDP. I think.

ingressRoute crd exists because builtin ingress isn't quite good enough. so it'll probably live on a good while.

What is super buzzwordy to you?