Kubernetes releases ingress2gateway tool for upcoming GA of Gateway API | Hacker News Reader

Kubernetes releases ingress2gateway tool for upcoming GA of Gateway API

kubernetes.io

149 pointskodama-lens35 comments

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

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.

Since it makes no mention of ipv4 or ipv6 I'm going to hope it's underlying ip protocol agnostic and works in the UDP/TCP level only, which would encompass all TLS and QUIC behaviours too.

Past experience with k8s suggests this hope is prone to being wishful thinking.

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.

Welp, I wonder when this will make sense to look at -- I'm pretty happy with `IngressRoute`[0] and related CRDs that are used with traefik.

I guess when traefik goes all-in on gateway (they were one of the earliest with support for it), then it will make sense.

[0]: https://doc.traefik.io/traefik/routing/providers/kubernetes-...

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

Note that I was talking about Gateway, which is the tool that the original article is about. I was referring to whether it would make any sense for me to move from IngressRoute to Gateway any time soon.

Aye that's what I meant, if you're happy with ingressRoute you've probably got a longer migration clock than just Ingress as traefik has an additional vested interest in keeping it working. It might even be able to be re-implemented into a gatewayClass without changes.

The problem with IngressRoute is that Helm charts are mostly using Ingress. Luckily, traefik have solved this through the use of annotations, which allows me to avoid using IngressRoute entirely.

Ah that's clever, I avoided it because it's a same-but-different technology and I try to avoid leaving the defaults. Just ingress wasn't so bad that was worth it. That is a good solution though.

Ahh got you, thanks for the note!

Tools like istio provide this sort of functionality currently, right? Does this adding anything to that?

I wonder how developers will be able to develop extensions for it.

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.

There is experimental support for basic http timeouts now - https://gateway-api.sigs.k8s.io/geps/gep-1742/#api

I can't ever debug anything on Istio, it is like playing around with configurations hoping to finally sort it out, usually takes a couple of hours to sort every issue.

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...

every day, kubernetes strays further from god's light

I hate when open source projects (especially common in the Kube-sphere I feel) adopt these super buzzwordy roles in their announcements.

What is super buzzwordy to you?

API Gateway is a bit of a buzzword. I think part of it's because of Amazon API Gateway. People like to imagine they're recreating big parts of AWS, and a lot of Amazon's other products have names that are trademarked or are clunky to use.

I mean, the title says Gateway API, because it's literally about an API named Gateway. Idk how you avoid it.

The text repeats it a lot. Maybe more than it should. Also GatewayClasses. It’s nitpicky, but I’m trying to understand OP’s comment.

The Kubernetes API is structured as "resources". (I'm oversimplifying but it's OK for what we are going to explain here).

In this case. Gateway is merely a new resource type introduced to replace the aging and inadequate Ingress resource. GatewayClass was introduced alongside it as a way for the infrastructure providers to define essentially a "template" for how Gateways can be created that are tied back to a specific implementation.

This is similar to how StorageClass and PersistentVolume (two other resources) already work for defining block storage in Kubernetes.

This isn't buzzword soup and the original commenter just has no clue what they are talking about so there isn't any point in defending their potential point because there isn't one there. The text repeats these terms a lot because they are what are being discussed, as in -concrete- things. Not buzzwords.

FWIW I hate buzzwords, marketing and pretty much everything else of that ilk. Talk is cheap, show me the code. In this case, this is the code.

I understand what GatewayClass means and still think it could have been repeated less. I didn't say it was buzzword soup. I think it's good but I wouldn't want this to become the prevailing style.

This paragraph:

> Subsequently, cluster operators utilize these GatewayClasses to deploy gateways. A Gateway in Kubernetes' Gateway API defines how external traffic can be directed to Services within the cluster, essentially bridging non-Kubernetes sources to Kubernetes-aware destinations. It represents a request for a load balancer configuration aligned with a GatewayClass’ specification. The Gateway spec may not be exhaustive as some details can be supplied by the GatewayClass controller, ensuring portability. Additionally, a Gateway can be linked to multiple Route references to channel specific traffic subsets to designated services.

Unfortunately, in terms of Kubernetes this is written pretty clearly about what it’s doing and how it interacts with other parts.

Well it's the subject of the vast majority of the sentences. I fail to see how you can write this information in a way that doesn't use it multiple times without going out of your way to imply the subject instead of just stating it clearly as is done here.

Especially that API Gateway used to encompass several more services provided by middlewares than the rather limited AWS one.

Since I got downvoted, anyone could explain what is incorrect with my statement?

It's OK, but almost impossible to search.

At least when using Google search where double-quotas seem to be not always understood as the "required term" anymore.

Reply on news.ycombinator.com