Proposal: Replace Heavyweight Network Layer with Kubernetes Gateway API for Path-Based Routing and Lightweight Deployment

[Bryce-huang]

Describe the feature

Problem Statement
Knative Serving forces users to install a heavyweight network layer (e.g., Istio, Kourier), which has two critical drawbacks:

Excessive Complexity and Resource Overhead: Istio/Kourier require additional control plane components (e.g., Envoy proxies, Gateway controllers), increasing cluster resource consumption and maintenance costs.

Lack of Native Path-Based Routing: Current Knative network layers do not natively support path-based routing configurations (e.g., /api/v1 → Service A, /static → Service B), forcing users to manually hack Istio VirtualService or use experimental workarounds.

This contradicts the Kubernetes ecosystem's trend toward lightweight standardization (e.g., Gateway API).

User Pain Points
"Why do I need Istio just to split traffic by path?": Users are frustrated by mandatory network components for basic routing needs.

"Knative should be simpler!": The extra network layer complicates deployments, especially in edge or resource-constrained environments.

"Gateway API already solves this!": Kubernetes Gateway API (stable since v1.28) provides path-based routing and traffic splitting, making Knative’s custom network layer redundant.

Proposed Solution
Integrate Kubernetes Gateway API as the default network layer, allowing users to:

Skip installing Istio/Kourier entirely.

Define path-based routing directly in Knative via Gateway API’s HTTPRoute (example below).

Simplify canary releases using Gateway API’s built-in traffic splitting.

Example Path-Based Routing with Gateway API:

# Knative Service + Gateway API Path Routing
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
spec:

  template:
    spec:
      containers:
        - image: my-app:latest
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-app-routes
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: "/api"
      backendRefs:
        - name: my-app
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: "/static"
      backendRefs:
        - name: static-assets-service
          port: 80

Why This Matters
Alignment with Kubernetes Standards: Gateway API is the future of Kubernetes ingress, reducing fragmentation.

Path-Based Routing Out of the Box: No need for Istio CRDs or manual VirtualService patches.

Using k8s Gatewaw API can easily allow more gateways to access knative

Implementation Roadmap
Phase 1: Add a network-layer: none option to Knative Serving installation, disabling Istio/Kourier.

Phase 2: Implement Gateway API adapter to reconcile Knative Route → HTTPRoute.

Phase 3: Deprecate legacy network layers in favor of Gateway API (opt-in).

[Bryce-huang]

Dear knative commiter, we have good practical experience in using gateway api to replace knative network components in our production environment. Using gateway api will completely decouple the dependent gateway implementation, instead of only a few gateways can access knative as it is now. If there is a plan, I can contribute pr for this.

[dprotaso]

We have a Gateway API integration available at https://github.com/knative-extensions/net-gateway-api

Phase 2: Implement Gateway API adapter to reconcile Knative Route → HTTPRoute.

This is our long term plan but we're waiting for supported features in Gateway API first.

Note just switching to Gateway API doesn't really make installing the 'networking layer' much easier. Even by using the Gateway API will require you to select an implementation such as Istio, Contour, Envoy Gateway etc.

[dprotaso]

Also note - your example below is currently not possible with the Gateway API. It's been something I've been wondering for a while and I'll surface this in a Gateway API discussion to see what the maintainers think. But essentially the backendRefs when you point to a Knative Service would need some way for gateway implementations to know where to route to

# Knative Service + Gateway API Path Routing
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - image: my-app:latest
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-app-routes
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: "/api"
      backendRefs:
        - name: my-app
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: "/static"
      backendRefs:
        - name: static-assets-service
          port: 80