[Feature Request] Support service discovery for Kubernetes Gateway API

[Exeteres]

Description

Similar to IngressRoute from Traefik, it would be very nice to support the Gateway API, which is intended to replace both Ingress and IngressRoute.

Other

No response

[djeinstine]

Hi @Exeteres . I have created a PR for this feature here #4289. Currently pending review.

[Bricklou]

I would also be interested into this feature. It would be a nice addition to the project. Especially since the Kubernetes team has stabilized most of the APIs and that many Kubernetes projects already support it (or, at least, are almost done supporting it).

Similar to IngressRoute from Traefik, it would be very nice to support the Gateway API, which is intended to replace both Ingress and IngressRoute.

I have to correct you about this, though : it isn't there to replace Ingress and IngressRoute. It is there as an alternative way to expose services.

[xerox81]

I'm also interested into this feature. Usage of the Gateway API is on the rise right now.

[dudo]

I just stumbled across this before submitting my own feature request. I see that the PR was closed due to "not meeting the requirements in terms of community interest." That seems a bit myopic...

I looked at the code, and there are some things to address (namely the conditional checks, since this isn't an either/or to @Bricklou's point that GAPI isn't meant to replace Ingress), but I think we should push forward with the change. I can help review and test.

[Bricklou]

I'm also willing to volunteer to do some testing on my side. Just ping me when it is “ready” to be tested.

[dudo]

I can appreciate your trepidation, @shamoon. For many of us, though, Kubernetes is the only thing we use 😅 . The original code in this area was a bit convoluted, so I'm not surprised that any changes to that code caused issues.

I'm well versed in js and K8s, and can help clean things up.

[dudo]

@djeinstine you wanna open another PR with that same branch, and we can move the conversation over there?

[djeinstine]

hi @dudo. See PR #4643.

[github-actions[bot]]

This discussion has been automatically closed because it was marked as answered. See our contributing guidelines for more details.

[dudo]

@djeinstine @Bricklou @shamoon

I'm seeing an error in the logs while testing dev.

[2025-02-13T04:34:44.930Z] error: <resource-helpers> Error getting gateways: NaN undefined undefined
[2025-02-13T04:34:44.931Z] debug: <resource-helpers> TypeError: Cannot read properties of undefined (reading 'protocol')

I'm seeing a couple bugs here

• listner is misspelled
• It can be nil (per the logs)
• The issue appears to be with gatewayRef.sectionName. It's optional, per the spec, and I'm not using it.
  • This can be refactored to gracefully fail, then fallback to the first entry (unfiltered)

Permission to open a PR?

[shamoon]

Sure

[shamoon]

I assume this will do it:

      let listener = response.spec.listeners.find((listener) => listener.name === gatewayRef.sectionName);
      if (!listener) {
        logger.warn("No listener found for gateway %s, falling back to first listener", gatewayRef.name);
        listener = response.spec.listeners[0];
      }
      return listener.protocol.toLowerCase();

[dudo]

https://github.com/gethomepage/homepage/pull/4752/files

I don't think a warn is necessary, since the field is optional.

[dudo]

@shamoon Looks like we have a regression with /api/widgets/kubernetes

I'm hitting this line (which doesn't actually log an error). I checked the PR, and though that file was touched, it doesn't appear to be related.

[djeinstine]

It was indeed. And the sneaky thing, was it would only affect kubernetes users. Glad it was caught early.

[dudo]

@shamoon I found other instances of .body usage against the new 1.0 SDK in that PR.

[shamoon]

I think they're already corrected in dev but let me know if not

[dudo]

Oh! I don't know how I missed that... I thought I bumped my fork with upstream. Just double checked, and you got 'em. Cheers!

[shamoon]

dev has been re-built for whenever you guys have a chance to re-check

[dudo]

Everything confirmed and working nicely.

Thanks again, @djeinstine ! Great work.

[hemstreet]

@dudo @djeinstine can you share some of your setup. I'd like to try this out as I'm hitting some issues getting this up and running.

My first stab was at the unofficial helm chart which, maybe that's why i am having troubles.

I assume at this point you are using the docker image's dev tag, and this is hot off the press / bleeding edge.

Can your share your manifest if possible? I'd love to give this a try and deploy it out into my cluster.

[dudo]

https://github.com/dudo-home-lab/homepage-deployment/tree/main/base

I'm not sure if the helm chart has the rbac updated yet.

[hemstreet]

I got it working using Argo and the helm chart. I just overrode the image, used the dev tag and added in the RBAC roles via the helm chart values file.

apiVersion: v1
kind: Namespace
metadata:
  name: homepage
  annotations:
    argocd.arggoproj.io/sync-wave: "-1"
---
# https://github.com/jameswynn/helm-charts/blob/main/charts/homepage/values.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: homepage
  namespace: argocd
  finalizers:
    - "resources-finalizer.argocd.argoproj.io"
spec:
  project: default
  source:
    repoURL: https://jameswynn.github.io/helm-charts
    chart: homepage
    targetRevision: 2.0.1
    helm:
      valuesObject:
        env:
          - name: "HOMEPAGE_ALLOWED_HOSTS"
            value: dashboard.{{.Values.cluster_domain}}
          - name: "LOG_LEVEL"
            value: debug
        image:
          repository: ghcr.io/gethomepage/homepage
          tag: dev
        enableRbac: true
        serviceAccount:
          create: true
          name: homepage
        extraClusterRoles:
          - apiGroups:
              - gateway.networking.k8s.io
            resources:
              - httproutes
              - gateways
              - grpcroutes
            verbs:
              - get
              - list
        config:
          settings: []

          kubernetes:
            mode: cluster
            route: gateway
            gateway: "true"
          bookmarks: []
          services: []
          widgets:
            - kubernetes:
              cluster:
                show: false
                cpu: true
                memory: true
                showLabel: true
                label: "cluster"
              nodes:
                show: true
                cpu: true
                memory: true
                showLabel: true
            - resources:
                label: Network
                network: true
                expanded: true
            - resources:
                label: Temperature
                cputemp: true
                tempmin: 0
                tempmax: 100
                expanded: true
            - search:
                provider: google
                target: _blank
                persistence:
                  logs:
                    enabled: false
  destination:
    server: https://kubernetes.default.svc
    namespace: homepage
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: homepage
  namespace: homepage
  annotations:
    gethomepage.dev/description: Dynamically Detected Homepage
    gethomepage.dev/enabled: "true"
    gethomepage.dev/group: Cluster Management
    gethomepage.dev/icon: homepage.png
    gethomepage.dev/name: Homepage
spec:
  hostnames:
    - dashboard.{{ .Values.cluster_domain }}
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: {{ .Values.gateway_name }}
      namespace: external-dns
  rules:
    - backendRefs:
        - group: ""
          kind: Service
          name: homepage
          port: 3000
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /
           

[arthur-leclerc]

Hello, has anyone managed to get the feature working with more than one HTTP route?

It seems impossible to expose more than one route on the Homepage. Taking the example above, I would expect this additional configuration:

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
-  name: homepage
+  name: homepage-2
  namespace: homepage
  annotations:
    gethomepage.dev/description: Dynamically Detected Homepage
    gethomepage.dev/enabled: "true"
    gethomepage.dev/group: Cluster Management
    gethomepage.dev/icon: homepage.png
-    gethomepage.dev/name: Homepage
+    gethomepage.dev/name: Homepage - 2
spec:
  hostnames:
-    - dashboard.{{ .Values.cluster_domain }}
+    - dashboard-2.{{ .Values.cluster_domain }}
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: {{ .Values.gateway_name }}
      namespace: external-dns
  rules:
    - backendRefs:
        - group: ""
          kind: Service
          name: homepage
          port: 3000
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /

to expose the route again on the Homepage, but that's not the case. I've also tried with a second Gateway API, there's always only one route exposed, the first HTTPRoute in the ascending order by metadata.name.

Thank you for your help !

Update: See #4865

[arthur-leclerc]

Thank you for your example, but I later realized that my problem was when I tried to attach two HTTPRoute defined in the same namespace. Only one HTTPRoute was returned, which is now fixed with this PR.

Edit: Response to a removed message