Gateway API Integration with Kamaji

[alfredosa]

I opened a PR (#1000) before opening an Discussion here. I am currently working with Kamaji and believe the separation of concerns that the Gateway API offers is highly attractive for a project like this. Since Kubernetes is heavily invested in the Gateway API, we wanted to help Kamaji introduce the feature.

The scope

To achieve the functionality, we want to extend the controller to manage TLSRoutes. This would allow a user to bring their own Gateway and define a new gatewaySpec (similar to the existing ingressSpec) on the TenantControlPlane resource.

This gatewaySpec would allow:

• Referencing the parent Gateway via parentRefs
• Specifying hostnames for SNI matching
• Adding annotations (via existing metadata spec)
• Adding labels (via existing metadata spec)

Overall the scope is small and would only add the functionality of resources, ownership of those resources. Then on each TCP creation we can have the Routes pointed to the Service.

Idea is to create those BackendRefs very similarily as the Ingres does right now.

[prometherion]

It's definitely something I'm looking into it: Ingress or Gateway API is just a matter of implementation.

[hadrienk]

Hello, pitching in with some thoughts as I was looking at the code. Keep in mind, I just started so my apologies if I overlooked anything.

Both ingress and Gateway API use hostnames. As far as I now the current way to set the hostname is using the hostname field in the ingress spec, or via the networkProfile with support for using a pattern based generation: id.domain.tld.

When using service with LoadBalancer it's unclear how the hostname is set, if is it at all?

It seems to me that the controller spec could express the domain generation (or set value) only in one place instead. Ingress and Route can put the generated address in the hostnames. Service can be set up to add an annotation with the value.

[prometherion]

Regarding hostname, we never supported that from day-0 since Kubernetes is entirely based on the concept of --advertised-address flag in the API Server: you can reach out to the API Server using a FQDN and relying on L7/SNI routing, but internal workloads will still rely on IP routing (such as the kubernetes.default.svc Cluster IP being resolved by the kube-proxy, or the CNI, to an IP address).

We could change this approach and rely rather on FQDN or IP addresses: this would require a broader discussion and sharing the change with the community. Although under frequent development phases, Kamaji is widely adopted and shaping its future: we need to pay attention to adopters already using that in mission-critical environments.

[prometherion]

Implemented via #1000