Envoy Gateway doesn't work with Knative

[dprotaso]

This is a tracking issue for an upstream bug that breaks traffic splitting - envoyproxy/gateway#5230

/triage accepted

[arkodg]

should be resolved, can you try again @dprotaso ?
also can we update

net-gateway-api/hack/test-env.sh

Line 23 in 58602c7

export ENVOY_GATEWAY_VERSION="v1.2.5"

to use v0.0.0-latest so its easier to track any regression in the future

[kahirokunn]

I verified it in v1.5.4, and it is functioning normally.

[em-sav]

Hey @kahirokunn, how did you get this to work? I'm running a simple test with EnvoyGateway to expose a service over HTTP, but I'm getting 503 errors at the gateway.

envoy [2026-01-11T03:48:07.547Z] "GET /status/200 HTTP/1.1" 503 - 0 0 0 "172.18.0.1" "curl/8.7.1" "24a970d8-fbf9-4738-8892-5481afce1598" "knative-serving.cncf.demo" "-"
envoy [2026-01-11T03:48:25.624Z] "GET / HTTP/1.1" 503 - 0 0 0 "10.244.1.22" "Knative-Ingress-Probe" "6f58ca98-c491-4167-bd3e-3075ec2ab38d" "knative-serving.cncf.demo" "-"

I've been experiencing this issue for a while with EG and suspect that the host-rewrite functionality isn't working properly with EnvoyGateway as mention.

My External HTTPRoute appears to be configured correctly, but the urlRewrite that should forward requests to the Internal HTTPRoute doesn't seem to be functioning. Both routes are generated by Knative through the net-gateway-api plugin using my DomainMapping and Claim.

Domain Mapping + Claim

apiVersion: networking.internal.knative.dev/v1alpha1
kind: ClusterDomainClaim
metadata:
  name: knative-serving.cncf.demo
spec:
  namespace: workload
---
apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
  name: knative-serving.cncf.demo
  namespace: workload
spec:
  ref:
    apiVersion: serving.knative.dev/v1
    kind: Service
    name: cncf-server
    namespace: workload

External HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: knative-serving.cncf.demo
  namespace: workload
spec:
  hostnames:
  - knative-serving.cncf.demo
  parentRefs:
  - name: knative-gateway
    namespace: gateway
  rules:
  - backendRefs:
    - filters:
      - requestHeaderModifier:
          set:
          - name: K-Original-Host
            value: knative-serving.cncf.demo
        type: RequestHeaderModifier
      name: cncf-server
      port: 80
    filters:
    - requestHeaderModifier:
        set:
        - name: K-Network-Hash
          value: fbc466689545331b7d591abca1ae387f5d09e481e1f946ab0cbcda76e0106397
      type: RequestHeaderModifier
    - type: URLRewrite
      urlRewrite:
        hostname: cncf-server.workload.svc.cluster.local
    matches:
    - headers:
      - name: K-Network-Hash
        type: Exact
        value: override
      path:
        type: PathPrefix
        value: /
    timeouts:
      request: 0s
  - backendRefs:
    - filters:
      - requestHeaderModifier:
          set:
          - name: K-Original-Host
            value: knative-serving.cncf.demo
        type: RequestHeaderModifier
      name: cncf-server
      port: 80
    filters:
    - type: URLRewrite
      urlRewrite:
        hostname: cncf-server.workload.svc.cluster.local
    matches:
    - path:
        type: PathPrefix
        value: /
    timeouts:
      request: 0s

Internal HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cncf-server.workload.svc.cluster.local
  namespace: workload
spec:
  hostnames:
  - cncf-server.workload
  - cncf-server.workload.svc
  - cncf-server.workload.svc.cluster.local
  parentRefs:
  - name: knative-gateway
    namespace: gateway
  rules:
  - backendRefs:
    - filters:
      - requestHeaderModifier:
          set:
          - name: Knative-Serving-Namespace
            value: workload
          - name: Knative-Serving-Revision
            value: cncf-server-00001
        type: RequestHeaderModifier
      name: cncf-server-00001
      port: 80
    filters:
    - requestHeaderModifier:
        set:
        - name: K-Network-Hash
          value: 59076927154f9e22aad8fbc09413773dfc0344b403172b1597a0daec07ee2724
      type: RequestHeaderModifier
    matches:
    - headers:
      - name: K-Network-Hash
        type: Exact
        value: override
      path:
        type: PathPrefix
        value: /
    timeouts:
      request: 0s
  - backendRefs:
    - filters:
      - requestHeaderModifier:
          set:
          - name: Knative-Serving-Namespace
            value: workload
          - name: Knative-Serving-Revision
            value: cncf-server-00001
        type: RequestHeaderModifier
      name: cncf-server-00001
      port: 80
    matches:
    - path:
        type: PathPrefix
        value: /
    timeouts:
      request: 0s

When I test from inside the cluster, Knative works as expected by scaling the Pod and sending traffic to the right revision by going through the internal-knative-gateway: curl http://cncf-server.workload.svc.cluster.local

cc: @dprotaso 🙏

[kahirokunn]

I've written a blog post, and I hope you find it helpful. 😊
https://dev.to/kahirokunn/extending-knative-service-with-envoy-gateway-integration-56ak

[em-sav]

Hey man, thank you so much for the article. With it I was able to make Knative work with EnvoyGateway. Also, I was able to pinpoint what was causing the error on my end.

Basically, it is the DomainMapping and ClusterDomainClaim that don't work with net-gateway-api. I feel like it's the urlRewrite in each backendRef that doesn't behave as expected. And DomainMapping creates that new route with a hostname rewrite to send through the internal Gateway. So by removing this and setting my default domain through the config-domain ConfigMap I was able to access my service externally with my root domain suffix.

I might open a separate issue for further investigation on the DomainMapping incorrect behavior.

Thanks again

[kahirokunn]

I'm glad it seems to have been helpful to you. 😄

[em-sav]

For those who are interested, I've updated my Knative + Gateway API CNCF presentation repository to use only Envoy Gateway. Much simpler and more powerful for advanced ingress features.