Hacker News Reader

Comment by robertlagrant | Hacker News Reader

I've not used Gateway, but I have felt the pain and confusion of Ingress. Hopefully this simplifies things for our Devops/SRE heroes.

View on HN

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

> route by query string, configure weighted load balancing, work with TLS, deal with methods, etc - let alone other protocols than HTTP

Except for weighted load balancing*, these are all things NGINX does, which Kong is built on via OpenResty, right? What makes Kong different? (Trying to be open to explore even though I was disappointed when Insomnia users got locked out of their data unless they signed up for an account when they updated what was marketed as an open source project)

* Which I think NGINX Plus, a competitor, probably has, and they have an Ingress controller for Kubernetes that would likely get updated to use the Gateway API soon.

> What makes Kong different?

I am specifically talking just about OSS functionality in the Kong Ingress Controller. It can assign weights to service backends.

And, FWIW, Insomnia 8.3 defaults to local projects (again)

https://konghq.com/blog/product-releases/insomnia-8-3

Gateway API is a broad community standard governed by SIG Network - fingers crossed for various other implementations (including mesh) working their way to GA implementation-wise - this will make the standard stronger and the community more vibrant.

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.

Since 2018-2019, many of the really big Kubernetes users ditched Ingress for custom controllers and CRDs that allowed for more flexible configuration.

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.

Reply on news.ycombinator.com