6 ms·

Kubernetes releases ingress2gateway tool for upcoming GA of Gateway API

149 points by kodama-lens 3y ago

robertlagrant 3y ago
I've not used Gateway, but I have felt the pain and confusion of Ingress. Hopefully this simplifies things for our Devops/SRE heroes.
- mflendrich 3y ago
  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/guides/getting-started/ https://docs.konghq.com/kubernetes-ingress-controller/2.12.x... [2] https://docs.konghq.com/kubernetes-ingress-controller/2.12.x/guides/using-ingress-with-grpc/ https://docs.konghq.com/kubernetes-ingress-controller/2.12.x... [3] https://github.com/Kong/kubernetes-ingress-controller https://github.com/Kong/kubernetes-ingress-controller
  - benatkin 3y ago
    > 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.
    - mflendrich 3y ago
      > 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 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.
- pram 3y ago
  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.
  - dharmab 3y ago
    Since 2018-2019, many of the really big Kubernetes users ditched Ingress for custom controllers and CRDs that allowed for more flexible configuration.
- sofixa 3y ago
  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.
pylua 3y ago
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.
- kbumsik 3y ago
  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/#implementations https://gateway-api.sigs.k8s.io/implementations/#implementat...
- gaganyaan 3y ago
  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.
  - dilyevsky 3y ago
    There is experimental support for basic http timeouts now - https://gateway-api.sigs.k8s.io/geps/gep-1742/#api https://gateway-api.sigs.k8s.io/geps/gep-1742/#api
  - pjmlp 3y ago
    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.
sheepo39 3y ago
I hate when open source projects (especially common in the Kube-sphere I feel) adopt these super buzzwordy roles in their announcements.
- kbumsik 3y ago
  What is super buzzwordy to you?
  - benatkin 3y ago
    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.
    - theossuary 3y ago
      I mean, the title says Gateway API, because it's literally about an API named Gateway. Idk how you avoid it.
      - benatkin 3y ago
        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.
        jpgvm 3y ago
        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.
ggm 3y ago
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.
- jpgvm 3y ago
  The Gateway spec itself supports both v4 and v6 addresses: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.AddressType https://gateway-api.sigs.k8s.io/reference/spec/#gateway.netw... More importantly you will want to check your specific Gateway implementation for support.
- Already__Taken 3y ago
  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.
denkmoon 3y ago
every day, kubernetes strays further from god's light
hardwaresofton 3y ago
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-crd/#kind-ingressroute https://doc.traefik.io/traefik/routing/providers/kubernetes-...
- Already__Taken 3y ago
  ingressRoute crd exists because builtin ingress isn't quite good enough. so it'll probably live on a good while.
  - hardwaresofton 3y ago
    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.
    - Already__Taken 3y ago
      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.
      - hardwaresofton 3y ago
        Ahh got you, thanks for the note!
      - no_carrier 3y ago
        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.

149 points by kodama-lens 3y ago

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

mflendrich 3y ago
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/guides/getting-started/ https://docs.konghq.com/kubernetes-ingress-controller/2.12.x... [2] https://docs.konghq.com/kubernetes-ingress-controller/2.12.x/guides/using-ingress-with-grpc/ https://docs.konghq.com/kubernetes-ingress-controller/2.12.x... [3] https://github.com/Kong/kubernetes-ingress-controller https://github.com/Kong/kubernetes-ingress-controller
- benatkin 3y ago
  > 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.
  - mflendrich 3y ago
    > 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 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.
pram 3y ago
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.
- dharmab 3y ago
  Since 2018-2019, many of the really big Kubernetes users ditched Ingress for custom controllers and CRDs that allowed for more flexible configuration.
sofixa 3y ago
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.

pylua 3y ago

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.

kbumsik 3y ago
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/#implementations https://gateway-api.sigs.k8s.io/implementations/#implementat...
gaganyaan 3y ago
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.
- dilyevsky 3y ago
  There is experimental support for basic http timeouts now - https://gateway-api.sigs.k8s.io/geps/gep-1742/#api https://gateway-api.sigs.k8s.io/geps/gep-1742/#api
- pjmlp 3y ago
  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.

sheepo39 3y ago

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

kbumsik 3y ago
What is super buzzwordy to you?
- benatkin 3y ago
  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.
  - theossuary 3y ago
    I mean, the title says Gateway API, because it's literally about an API named Gateway. Idk how you avoid it.
    - benatkin 3y ago
      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.
      - jpgvm 3y ago
        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.

ggm 3y ago

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.

jpgvm 3y ago
The Gateway spec itself supports both v4 and v6 addresses: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.AddressType https://gateway-api.sigs.k8s.io/reference/spec/#gateway.netw... More importantly you will want to check your specific Gateway implementation for support.
Already__Taken 3y ago
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.

denkmoon 3y ago

every day, kubernetes strays further from god's light

hardwaresofton 3y ago

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-crd/#kind-ingressroute https://doc.traefik.io/traefik/routing/providers/kubernetes-...

Already__Taken 3y ago
ingressRoute crd exists because builtin ingress isn't quite good enough. so it'll probably live on a good while.
- hardwaresofton 3y ago
  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.
  - Already__Taken 3y ago
    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.
    - hardwaresofton 3y ago
      Ahh got you, thanks for the note!
    - no_carrier 3y ago
      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.