frontend: add support for gateway-api

[farodin91]

How to test

Testing with Minikube and Envoy

• Follow these instructions https://gateway.envoyproxy.io/docs/tasks/quickstart/ , and use the "Without Loadbalancer support" tab on the "Testing the Configuration" step.
• Run Headlamp with this branch and click on the gateway sidebar menus.

Testing done

• smoke tested with minikube and envoy gateway
• tested it with a remote cluster that doesn't have any gateways used (and it reports not gateways successfully)
• checked fields against API specs
• reviewed component states in storybook

Future work

This is stuff out of scope of this PR. (We should probably add an issue for that)

• experimental features
• Testing with a service mesh, and mesh related gateway functionality
• add better http route rule UX (filters, backends,...)
• add tls UX to gateway
• add gateway api to map feature
• ...

[farodin91]

@joaquimrocha I'm not sure, if it's better to move this into a plugin or make gateway more present. This only adds stable resources.

What do you think? Views can be improved.

[illume]

Hi @farodin91

@joaquimrocha (and rest of team) has been busy the last days with very many release related things, and also some holidays.

To plugin or not? The gateway API is part of the Kubernetes project, so in that sense maybe it should be in Headlamp... but yeah... it's not a core Kubernetes thing. The other question to ask, is how commonly it's used? To me it's not entirely clear where it should be. Maybe you could provide more context?

[farodin91]

@illume i think Kubernetes is pushing gateway API for the last month quiet hard. I would say. It's now stable.

[illume]

@joaquimrocha Yeah, I agree it should go in headlamp rather than a plugin. This week I was learning about gateway API. Basically it’s the successor to Ingress. My understanding is gateway API is cleaning and standardizing things, and addressing missing spots (L4-L7 vs only http L7). As of the 1.2 release in October, quite a lot of the API is stable. There's several implementations of the http/TLS routers, less of the GRPC routers, and even fewer of the mesh routers (which is the main part left with experimental APIs AFAIK).

[farodin91]

@illume Would you like to review this PR? I think the ui can be improved or extend over time. Their is also a magic route called gateway, so i had to change route to k8sgateway. Do you have an idea why their is a magic route?

[illume]

Left some notes about API fields, and also a note about apiVersion should be v1 or both v1 and v1betav1?

[joaquimrocha]

@joaquimrocha Yeah, I agree it should go in headlamp rather than a plugin. This week I was learning about gateway API. Basically it’s the successor to Ingress.

Yeah, let's add it to the core.

[illume]

It takes quite a long time spinning on a cluster when there's no gateways. I don't think that should block this being merged, but something to look at at some point.

Same on a cluster with a gateway, but when there is no GRPC routes... the spinner takes quite a while before saying there are no routes.

[illume]

• I tested it with minikube and Envoy locally. ✅
• Also tested it with a remote cluster that doesn't have any gateways used. ✅

[illume]

Their is also a magic route called gateway, so i had to change route to k8sgateway. Do you have an idea why their is a magic route?

I can't find such a route in the Headlamp source. Also couldn't see something called 'gateway' in k8s outside of gateway API stuff. What about 'gatewayapi' as an alternative name to k8sgateway? Will have another look in the morning... maybe it's just too late.

[illume]

I think the ui can be improved or extend over time

I haven't tested with a mesh yet. Just from browsing the source, it looks like Mesh Profile isn't done yet? If it's not done, should we add that in future PRs?

It might be good to list anything missing you know of in a future work section of the PR description? Or we can start an issue I guess.

[illume]

btw, I presented Headlamp to some folks at Kubecon and asked them some questions about gateway API. They showed me a policy visualizer. There I also found out about gwctl https://github.com/kubernetes-sigs/gwctl?tab=readme-ov-file#visualizing-relationships-with-dot-graphs-using-gwctl-get--o-graph Also they told me about a gateway api sig meeting where we could take this to show them and get feedback if we want.

[farodin91]

Their is also a magic route called gateway, so i had to change route to k8sgateway. Do you have an idea why their is a magic route?

I can't find such a route in the Headlamp source. Also couldn't see something called 'gateway' in k8s outside of gateway API stuff. What about 'gatewayapi' as an alternative name to k8sgateway? Will have another look in the morning... maybe it's just too late.

is fixed now. it was the sidebar path.

[farodin91]

@illume i have updated the resource. What do you think?

[illume]

The container e2e test was shown as failed, and it looked like a temporary error so I reran it... and it passes now.

[illume]

I added an issue for the future work listed in the PR description:

• gateway API future work #2733

[illume]

Thanks!

I marked all of the convos resolved.

[sniok]

What's the strategy for clusters that don't support api gateway yet? Currently I'm getting a spinner