gateway-api sub-chart: allow HTTPRoutes to attach to an existing external Gateway instead of creating a new one

[deem1978]

Hello everyone,
as always first of all thank you very much for your work and your support.

Environment:

• Gluu CN 4.5, chart version 1.8.48 (upgrading to 1.8.49)
• Kubernetes 1.29
• Envoy Gateway as Gateway API implementation
• Managed shared Gateways in a dedicated envoy-gateway namespace

We are running Gluu CN 4.5 on Kubernetes (OTC / Open Telekom Cloud) with the following infrastructure model:

• Current routing: nginx-ingress sub-chart enabled, creating multiple Ingress resources that attach to a shared NGINX Ingress Controller managed by our platform team. All services across the organization share the same internal/public load balancers.
• Target routing: We are migrating from ingress-nginx to Envoy Gateway (Gateway API). Our platform team manages shared Gateway resources (internal-gateway, public-gateway) in a dedicated envoy-gateway namespace. Application teams only create HTTPRoute resources in their own
  namespaces, referencing the shared Gateway via parentRefs with a cross-namespace reference.
  This is the standard Gateway API ownership model described in the Gateway API documentation: infrastructure providers own Gateway, application developers own HTTPRoute.
  Our current Gluu deployment (chart version 1.8.48) generates Ingress resources, all attached to the shared platform LB.
  We would like to upgrade to chart version 1.8.49 and migrate to the gateway-api sub-chart.

Problem
After reviewing the gateway-api sub-chart templates, we found that there is no way to attach the generated HTTPRoutes to an existing, externally-managed Gateway. The sub-chart always creates its own self-contained Gateway + HTTPRoute stack.
Specifically:

1. gateway.yaml always creates a new Gateway resource
   charts/gateway-api/templates/gateway.yaml has no conditional guard — there is no enabled flag or {{- if }} block to skip Gateway creation:

  apiVersion: gateway.networking.k8s.io/v1
  kind: Gateway
  metadata:
    name: {{ .Values.gateway.name }}
    namespace: {{ .Release.Namespace }}
  spec:
    gatewayClassName: {{ .Values.gateway.className }}
    listeners:
    - name: http
      ...
    - name: https
      ...

In our setup, the Gateway resources are managed by the platform team in the envoy-gateway namespace. We do not want (and may not have RBAC permissions) to create Gateway resources in application namespaces.
2. HTTPRoute parentRefs lack a namespace field
charts/gateway-api/templates/route.yaml hardcodes parentRefs without a namespace:

  spec:
    parentRefs:
    - name: {{ .Values.gateway.name }}

Per the Gateway API spec, when namespace is omitted, the HTTPRoute looks for the Gateway in its own namespace. This makes it impossible to reference a Gateway in a different namespace (e.g., envoy-gateway).
3. sectionName values are hardcoded to http / https
The secure route uses sectionName: https and the redirect route uses sectionName: http:

  # routes-secure
  parentRefs:
  - name: {{ .Values.gateway.name }}
    sectionName: https

  # routes-redirect
  parentRefs:
  - name: {{ .Values.gateway.name }}
    sectionName: http

Comparison with the nginx-ingress sub-chart
The nginx-ingress sub-chart follows a different (and more flexible) pattern:

• It creates Ingress resources that reference an external Ingress Controller via ingressClassName
• It does not create the Ingress Controller itself
• The ingressClassName is fully configurable via values (nginx-internal, nginx-public, etc.)
  This is analogous to how we expect Gateway API to work: the chart should create HTTPRoute resources that attach to an existing Gateway, not provision a new one.

Questions
Did I miss some setting and there is a way to attach HTTPRoute to an existing Gateway?
Is this behavior (always creating a new Gateway) intentional, or is support for external Gateways planned?
Thank you very much for your support.
Best,
Davide

[deem1978]

Hi guys,
it would be very useful to implement to possibility to have one route for /oxauth and one for /identity in order to manage the policies separately for each.
In the last improvements (thank you for your work and support), if I read it correctly, there is only one route for both /oxauth and /identity, see the template route.yaml (lines 176-268)

apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: {{ $fullName }}-routes-secure   # ← unique HTTPRoute
  spec:
    ...
    rules:
    {{- if .Values.routes.authServerEnabled }}
    - matches:
      - path:
          type: PathPrefix
          value: /oxauth          # ← oxauth
      backendRefs:
      - name: oxauth
        port: 8080
    {{- end }}
    {{- if .Values.routes.adminUiEnabled }}
    - matches:
      - path:
          type: PathPrefix
          value: /identity        # ← identity — same HTTPRoute
      backendRefs:
      - name: oxtrust
        port: 8080
    {{- end }}
    ... 

What do you think about it?
Best,
Davide

[pradhankukiran]

Hi @deem1978, opened #547 to address your request for separate /oxauth and /identity routes. While at it, I split all services into their own HTTPRoutes for consistency, this way any service can have independent policy attachment without needing another change later.
Let me know if this works for your use case, or if you'd prefer to keep the split limited to just /oxauth and /identity, happy to revert the rest.

[deem1978]

Hi @pradhankukiran wow thank you so much for taking care, really nice! I would say that split all services into their own HTTPRoute would be the best improvement, so we can manage for each service dedicated policies, it adds a lot of flexibility.
Thank you very much!