Add agentgateway provider support to the chart

[danehans]

Changes

• split gateway provider selection from the literal GatewayClass name
• render AgentgatewayParameters and wire Gateways to the agentgateway provider path
• let chart test prerequisites and Helm values follow the selected gateway provider
• refresh generated chart README/schema output and bump the chart to v1.4.0
• stabilize chart CI workflow dependencies and plugin installation

Testing

• helm lint charts/llm-d-infra
• helm template test charts/llm-d-infra --set gateway.provider=agentgateway
• ct install --charts charts/llm-d-infra --config ct-install.yaml --debug --helm-extra-args '--timeout 500s --kube-context kind-agentgateway-e2e' --helm-extra-set-args '--set gateway.provider=agentgateway'

Partially Fixes: #269

[danehans]

xref llm-d/llm-d#421 for the associated llm-d/llm-d changes

[danehans]

I reviewed this setting across both llm-d-infra and llm-d, and I think LoadBalancer is the right default for AgentgatewayParameters.spec.service.spec.type when gateway.provider=agentgateway (and the deprecated kgateway compatibility path).

[Gregory-Pereira]

This is really awesome - regretting it took me so long to review. I have a few suggested refactors here.

Refactor in this PR that we should go with:

• decoupling the gateway provider and the class name

Specific changes requested:

• move data-science-gateway-class to a classname of istio because OSSM uses this class name but its built on top of Istio

Refactor suggested:

• Refactor the way that we configure and pass the parameterRefs. We want to open the door to supporting everything that GIE supports. I want a common way to configure all those. I have proposed a solution above, take a look and see if you like it.
• Gateway Exposure type. I suggest we compute this taking 3 factors into account:
  1. Gateway provider's default exposure type - This is the chart’s opinionated default based on the gateway implementation.
  2. Users intended exposure behaviour - This is the user saying what kind of reachability they want, regardless of the provider default.
  3. Hard override for service type - here be dragons but let people do what they want

[Gregory-Pereira]

IIRC this was a stylistic thing to help distinguish what provider we have by the name easily. Should we do this for each provider? Or is that a bad practice?

[danehans]

Commit 3259ffb keeps the -istio suffix only for the gatewayClassName: istio path. The data-science-gateway-class stays unsuffixed while still using the Istio-backed ConfigMap path.

[Gregory-Pereira]

As discussed, I want to have a consistent place to configure the gateway. Every implementation may call this something unique but they all controll configuration of the gateway (ex: gatewayConfig for envoy AI gateway, gatewayParameters for istio and kgateway, AgentgatewayParameters for agentgateway).

My proposal is to have common configurations at the top level, ex:

gateway:
    provider: istio | kgateway ...
    gatewayParameters:
        enabled: true
        resources: {}
        logLevel: warn
    kgateway:
        floatingUserId: true
...

[danehans]

+1. I'll keep gateway.gatewayParameters as the user interface for common gateway configuration, with:

• Common knobs at the top level of gateway.gatewayParameters.
• Provider-specific knobs under nested provider blocks.

That should give us a scalable shape for additional GIE-supported gateways without making every implementation invent a different top-level values block.

[Gregory-Pereira]

/lgtm 🥳