Feature Request: Add hostnames field to AIGatewayRoute spec

[study-eq-eat-drink]

Feature Request: Add hostnames field to AIGatewayRoute spec

Description

AIGatewayRoute currently lacks a hostnames field, which is a standard field available in the Gateway API's HTTPRoute. Since AIGatewayRoute internally generates an HTTPRoute, adding hostnames support would allow the generated HTTPRoute to include hostname-based filtering — enabling domain/SNI-based routing without requiring changes to the Gateway listener configuration.

Use Case

In production environments, it is common to serve multiple domains through a single Gateway. For example:

• ai-llm.example.com → routes to self-hosted vLLM backends (AI traffic)
• api.example.com → routes to general API backends (non-AI traffic)

With the standard HTTPRoute, this is straightforward:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: vllm-route
spec:
  hostnames: ["ai-llm.example.com"]   # <-- domain-based filtering
  parentRefs:
    - name: my-gateway
  rules:
    - backendRefs:
        - name: vllm-backend

However, when migrating to AIGatewayRoute, there is no equivalent hostnames field:

apiVersion: aigateway.envoyproxy.io/v1alpha1
kind: AIGatewayRoute
metadata:
  name: vllm-route
spec:
  parentRefs:
    - name: my-gateway
  # hostnames: ["ai-llm.example.com"]   # <-- NOT AVAILABLE
  rules:
    - matches:
        - headers:
            - type: Exact
              name: x-ai-eg-model
              value: my-model
      backendRefs:
        - name: vllm-backend

Current Workarounds

Without hostnames in AIGatewayRoute, users must resort to one of these approaches:

1. Dedicated Gateway listener per hostname — Requires adding a new listener with hostname to the Gateway resource, and using parentRefs.sectionName in AIGatewayRoute to bind to it. This forces changes at the Gateway infrastructure level for what should be a route-level concern.

2. Separate Gateway per AI domain — Creates a dedicated Gateway for AI traffic. This results in additional LoadBalancer resources and DNS configuration changes.

Both workarounds add operational complexity and deviate from the Gateway API's standard pattern where hostname filtering is a route-level responsibility.

Proposed Solution

Add an optional hostnames field to AIGatewayRouteSpec, consistent with the Gateway API's HTTPRouteSpec.Hostnames:

apiVersion: aigateway.envoyproxy.io/v1alpha1
kind: AIGatewayRoute
metadata:
  name: vllm-route
spec:
  hostnames: ["ai-llm.example.com"]   # <-- proposed field
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - headers:
            - type: Exact
              name: x-ai-eg-model
              value: my-model
      backendRefs:
        - name: vllm-backend

The AI Gateway controller would pass this hostnames value through to the auto-generated HTTPRoute, enabling standard Gateway API hostname matching behavior.

Why This Matters

• Gateway API consistency — HTTPRoute supports hostnames; AIGatewayRoute should too, since it generates HTTPRoute internally.
• Simpler migration — Users migrating from HTTPRoute to AIGatewayRoute should not need to restructure their Gateway listeners.
• Multi-tenant / multi-domain — Organizations commonly serve different AI endpoints on different domains through a shared Gateway.

Relevant Links

• Gateway API HTTPRoute hostnames spec: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec
• AIGatewayRoute API Reference: https://aigateway.envoyproxy.io/docs/api/
• Related issue (additional matching fields): Request override based on model + tenant in AIGatewayRoute #695

[study-eq-eat-drink]

I'm willing to implement this and submit a PR if the approach is approved.

[nacx]

The proposed change LGTM. @yuzisun WDYT?