#Configure GatewayAPI Route

#Prerequisites

Please ensure that you have read the Installation documentation before proceeding.

#View

#Topology

The topology tab provides a visual representation of the route and its associated resources. It displays all policies attached to the route, along with their dependent resources (such as secrets referenced by SecurityPolicy), giving you a comprehensive view of the route's configuration.

Note: This feature is currently only available for HTTPRoute.

#Configuration

#Configuration Via Web Console

1. Navigate to Alauda Container Platform -> Networking -> Gateway -> Routes
2. Click the Create Route button

#Create HTTPRoute

#Create TCP/UDP Route

#Configuration Via YAML

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-443
  namespace: demo
spec:
  hostnames:
    - example.com
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: demo
      sectionName: https
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: echo-resty
          namespace: demo-space
          port: 80
          weight: 100
      filters: [] 
      matches:
        - path:
            type: Exact
            value: /a
      sessionPersistence:
        type: Cookie
        sessionName: a
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: tcp
  namespace: demo-space
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: demo
      sectionName: tcp
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: echo-resty
          port: 80
          weight: 100
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
  name: udp
  namespace: demo
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: demo
      namespace: demo
      sectionName: udp
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: echo-resty
          namespace: demo
          port: 53
          weight: 100

#Introduction

Each route is a CR defined by the GatewayAPI specification. For detailed information about the fields and configuration options for each route type, please refer to the official documentation: - HTTPRoute specification - TCPRoute specification - UDPRoute specification - GRPCRoute specification - TLSRoute specification

#Hostnames

The hostnames field in a Route is a string array. It follows the Hostname Intersection Rules.

#Publish to Listener

#In Web Console

In the web console, you can select multiple listeners to publish the route to. The available listener candidates are filtered based on the following criteria:

• User permissions: You must have access to the gateway's namespace (the project must include this namespace).
• Route namespace allowlist: The gateway listener's allowed route namespaces must include the route's namespace.
• Route kind matching: The route's kind (HTTPRoute, GRPCRoute, etc.) must match the listener's allowed route kinds.

For more complex cross-namespace scenarios, please refer to attaching to a gateway created in another namespace.

#In YAML

• The sectionName is the listener name.
• Routes can only be attached to listeners that support their specific kind.
• By default, routes can only be attached to listeners where the Gateway is in the same namespace.

For cross-namespace attachment, please refer to attaching to a gateway created in another namespace.

#Rules

Each route can contain multiple rules. Each rule consists of the following components:

#Matches

Defines the conditions that must be met for a request to be routed by this rule.

A rule can have multiple matches:

• Each match consists of multiple conditions (e.g., path, headers, query parameters, method)
• Conditions within a match use AND logic (all must be satisfied)
• Matches between each other use OR logic (any match can satisfy the rule)

Example: If Match-1 requires path=/api AND header=v1, and Match-2 requires query=test, then a request is routed if it matches either (path=/api AND header=v1) OR (query=test).

#Match Condition Types

#Match Condition References

#Filters

Specifies transformations or modifications to apply to requests/responses.

#Filter Types

Notes:

• RequestRedirect and URLRewrite cannot be used together on the same rule
• ReplacePrefixMatch is only compatible with a PathPrefix HTTPRouteMatch
• Header names are case-insensitive per RFC 7230
• Multiple values for same header must use RFC 7230 comma-separated format

#Filter References

#Backend

Defines the target service(s) where matching requests should be forwarded.

Each service can have a weight field to specify the proportion of traffic to be routed to that service.

#Advanced HTTPRoute Rule Settings

HTTPRoute rules support additional configuration fields, such as retry policies, timeouts, and other traffic management parameters.

#Timeouts

#Retry

#Session Persistence

Configures session affinity settings to ensure requests from the same client are routed to the same backend.

#Next Step

Tasks for Envoy Gateway

#Related Tasks

• How to attach to listener created in other namespace