Enable GatewayAPI Support

[stevesloka]

Gateway API is an open source project managed by the SIG-NETWORK community. It is a collection of resources that model service networking in Kubernetes. These resources - GatewayClass,Gateway, HTTPRoute, TCPRoute, Service, etc - aim to evolve Kubernetes service networking through expressive, extensible, and role-oriented interfaces that are implemented by many vendors and have broad industry support. (https://gateway-api.sigs.k8s.io/).

Describe the solution you'd like I was looking to add support for GatewayAPI inside of kube-vip and curious about a way to accomplish this. It replaces the functionality done by service type=LoadBalancer that exists today in the cloud provider repo (https://github.com/kube-vip/kube-vip-cloud-provider).

Is kube-vip open to adding support for GatewayAPI? We'd only need to add the TCP routing bits which would mimic the functionality done in service type=LoadBalancer, but would instead read a Gateway object with a TCPRoute which would point to a service in k8s to expose.

I'm happy to do the work, just wanted to discuss a bit about the implementation. =)

[thebsdbox]

Sounds great, I'd love to have this in Kube-Vip! Think it will take a lot of work?

[stevesloka]

I don't think it will be super hard, but you know how those statements always go. I think starting with TCPRoutes is a good start which would mimic service type=LoadBalancer.

Do you want me to piecemeal in things or just work up a prototype and see how bad that looks to review?

[thebsdbox]

The only requirement is not breaking how it works for existing users. So please go for it!

[thebsdbox]

Finally had chance to look into this in a bit more detail, would we need to implement a kube-vip gateway controller for this?

[stevesloka]

Yup we'd have to watch for GatewayClasses, Gateways, and at least TCPRoutes. If the Gateway found matches a GatewayClass with the GatewayClass.Controller matching the kube-vip default (I assume only a single instance of kube-vip per cluster), then kube-vip would find any TCPRoutes which reference a valid Gateway.

Once you get all that (:wipesbrow:), then essentially you've got a service type=LoadBalancer where the Gateway defines the external traffic and then routes to a service in the cluster defined by the TCPRoute.

I was thinking of spinning up the watches + conversions for the Classes, Gateways, and TCPRoutes, then adding in the extra processing. There's a bit of status work that needs to be done as well.

Happy to jump on a call or office hours if that makes this idea easier to hash out. =)

[thebsdbox]

Ah ok, that's kind of what I expected we would need anyway. It seems relatively straight forward (almost identical to a degree in the way things exist today).. So i'm happy to leave you to PoC this, although i'm happy to help out if I can too. :-)

[stevesloka]

Hey @thebsdbox, I've lost track of this with a new job, but would like to pick it up again. Do you have any implementation changes that might need to happen since I last looked a few months ago?

You might be at Kubecon now as well, so we can catch up another time. =)

[thebsdbox]

Ha! Yeah KubeCon overload at the moment 🤯

I'm happy with everything that we'd previously discussed.

[thebsdbox]

Hey @stevesloka is there anything that can be done to move this forward or is this something I should look at implementing myself?

[thebsdbox]

https://github.com/thebsdbox/gateway-api-controller @stevesloka I've pretty much managed to implement most of it here 😀

[stevesloka]

You're awesome @thebsdbox! Sorry for falling short on this a few times. 😞

[lexfrei]

Any news?