feat(helm): support OpenShift/Istio GatewayClass in grpcRoute values

[akram]

Problem Statement

The grpcRoute Helm values default to className: "eg" (Envoy Gateway). On OpenShift, Envoy Gateway cannot be installed because the Ingress Operator manages Gateway API CRDs and rejects third-party installations. Users who set grpcRoute.enabled=true on OpenShift get a Gateway resource referencing a non-existent GatewayClass.

OpenShift clusters have Istio-based Gateway controllers available (e.g. istio or data-science-gateway-class) that support GRPCRoute natively. However, these controllers require a DestinationRule for TLS origination to the backend when the gateway runs with TLS enabled (the default), which the chart does not create.

Proposed Design

Extend the grpcRoute values to support non-Envoy GatewayClasses and optionally create a DestinationRule for Istio-based controllers:

grpcRoute:
  enabled: true
  gateway:
    create: true
    className: "istio"  # or any GatewayClass name
  # Istio DestinationRule for TLS origination to the backend.
  # Required when the GatewayClass uses Istio and the gateway has TLS enabled.
  destinationRule:
    enabled: false
    insecureSkipVerify: true

Changes required

• deploy/helm/openshell/values.yaml — add grpcRoute.destinationRule.enabled and grpcRoute.destinationRule.insecureSkipVerify values
• deploy/helm/openshell/templates/ — add a new destinationrule.yaml template, conditioned on grpcRoute.destinationRule.enabled
• deploy/helm/openshell/templates/gateway.yaml — the Gateway listener TLS config should support mode: Terminate with certificateRefs (related to Support TLS termination for the Envoy Gateway ingress #2017)
• Update docs to show OpenShift/Istio example alongside the existing Envoy Gateway example

Alternatives Considered

1. Document manual resource creation only: Current workaround. Users create Gateway, GRPCRoute, and DestinationRule manually. Works but defeats the purpose of grpcRoute.enabled.

2. Add an OpenShift-specific ingress template: A separate template for OpenShift Routes (reencrypt). More OpenShift-native but adds platform-specific logic to the chart. Routes are simpler for most OpenShift users anyway — this proposal targets users who prefer the standard Gateway API.

3. Auto-detect GatewayClass: Query available GatewayClasses at render time. Not possible in Helm templates — they don't have runtime cluster access.

Agent Investigation

• Deployed on ROSA HCP 4.21 with grpcRoute.enabled=true and className: "eg": Gateway created but Programmed: Unknown because the eg GatewayClass doesn't exist.
• Attempted helm install eg oci://docker.io/envoyproxy/gateway-helm: rejected by the Ingress Operator ValidatingAdmissionPolicy with "Gateway API Custom Resource Definitions are managed by the Ingress Operator and may not be modified".
• Manually created Gateway with className: istio + GRPCRoute + DestinationRule: works end-to-end with HTTP/2 and gRPC.
• Verified oc get gatewayclass shows Istio-based classes with ACCEPTED: True.

Related

• Support TLS termination for the Envoy Gateway ingress #2017 — TLS termination for Envoy Gateway ingress (parallel effort)
• docs(openshift): expand OpenShift guide with TLS, OIDC, ingress, and federated identity #2091 / docs(openshift): expand OpenShift guide into multi-page section with TLS, OIDC, and ingress #2094 — OpenShift docs covering the manual Gateway API setup

---

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request