#Configure Gateway

An inbound gateway (Gateway) is an instance deployed from the Gateway Class. It creates listeners to capture external traffic on specified domain names and ports. Together with routing rules, it can route the specified external traffic to the corresponding backend instances.

Create an inbound gateway to enable more granular allocation of network resources.

#Terminology

#Prerequisites

The platform administrator must ensure that the cluster supports LoadBalancer type internal routing. For public cloud clusters, the LoadBalancer Service Controller must be installed. In non-public cloud clusters, the platform provides the external address pool feature, which allows LoadBalancer type internal routing to automatically obtain an IP from the external address pool for external access after configuration is complete.

#Example Gateway and Alb2 custom resource (CR)

# demo-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  namespace: k-1
  name: test
  annotations:
    cpaas.io/display-name: ces
    listeners.cpaas.io/creationTimestamp: '["2025-05-26T02:05:56.135Z"]'
    listeners.cpaas.io/display-name: '[""]'
  labels:
    alb.cpaas.io/alb-ref: test-o93q7
spec:
  gatewayClassName: exclusive-gateway
  listeners:
    - allowedRoutes:
        namespaces:
          from: All
      name: gateway-metric
      protocol: TCP
      port: 11782
---
apiVersion: crd.alauda.io/v2beta1
kind: ALB2
metadata:
  namespace: k-1
  name: test-o93q7
spec:
  type: nginx
  config:
    enableAlb: false
    networkMode: container
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi
    vip:
      enableLbSvc: true
      lbSvcAnnotations: {}
    gateway:
      mode: standalone
      name: test

#Creating Gateway by using the web console

1. Go to Container Platform.

2. In the left navigation bar, click Network > Inbound Gateway.

3. Click Create Inbound Gateway.

4. Refer to the following instructions to configure specific parameters.

   Parameter	Description
   Name	The name of the inbound gateway.
   Gateway Class	The gateway class defines the behavior of the gateway, similar to the concept of storage classes (StorageClasses); it is a cluster resource. Dedicated: The inbound gateway will correspond to a specific resource instance, and the user can utilize all listeners and computing resources of this gateway.
   Specification	You can choose the recommended usage scenario based on your needs or customize the resource limits.
   Access Address	The address of the inbound gateway, which is automatically obtained by default.
   Internal Routing Annotation	Used to declare the configuration or capabilities for LoadBalancer type internal routing. For specific annotation information, please refer to LoadBalancer type internal routing annotation instructions.

5. Click Create.

#Creating Gateway by using the CLI

kubectl apply -f demo-gateway.yaml

#Viewing Resources Created by the Platform

After the inbound gateway is created, the platform automatically creates many resources. Do not delete the resources below.

#Updating Gateways

#Updating Gateway by using the web console

1. Access the Container Platform.

2. In the left navigation bar, click Network > Inbound Gateway.

3. Click ⋮ > Update.

4. Update the inbound gateway configuration as needed.

   Note: Please set the specifications reasonably based on business requirements.

5. Click Update.

#Add Listener

Monitor traffic under specified domain names and forward it to backend instances according to the bound routing rules.

#Prerequisites

• If you need to monitor HTTP protocol, please contact the administrator in advance to prepare the domain name.

• If you need to monitor HTTPS protocol, please contact the administrator in advance to prepare the domain name and certificate.

#Add Listener by using the web console

1. In the left navigation bar, click Network > Inbound Gateway.

2. Click Inbound Gateway Name.

3. Click Add Listener.

4. Refer to the following instructions to configure specific parameters.

   Parameter	Description
   Listener Protocol and Port	Currently supports monitoring HTTP, HTTPS, TCP, and UDP protocols, and you can custom input the port to be monitored, for example: 80. Note: When the ports are the same, HTTP, HTTPS, and TCP listener types cannot coexist; you can only select one of the protocols. When using HTTP or HTTPS protocol, if the ports are the same, the domain names must be different.
   Domain Name	Select an available domain name in the current namespace, used to monitor network traffic accessing this domain name. Hint: TCP and UDP protocols do not support selecting domain names.

5. Click Create.

#Add Listener by using the CLI

kubectl patch gateway test \
  -n k-1 \
  --type=merge \
  -p '{
    "metadata": {
      "annotations": {
        "listeners.cpaas.io/creationTimestamp": "[\"2025-05-26T02:05:56.135Z\",\"2025-05-26T03:33:52.431Z\"]",
        "listeners.cpaas.io/display-name": "[\"\",\"\" ]"
      }
    },
    "spec": {
      "listeners": [
        {
          "allowedRoutes": {
            "namespaces": {
              "from": "All"
            }
          },
          "name": "gateway-metric",
          "protocol": "TCP",
          "port": 11782
        },
        {
          "allowedRoutes": {
            "namespaces": {
              "from": "All"
            }
          },
          "name": "demo-listener",
          "protocol": "HTTP",
          "port": 8088,
          "hostname": "developer.test.cn"
        }
      ]
    }
  }'

#Creating Route Rules

Route rules provide routing policies for incoming traffic, similar to inbound rules (Kubernetes Ingress). They expose network traffic monitored by the gateway to the internal routing of the cluster (Kubernetes Service), facilitating routing forwarding strategies. The key difference is that they target different service objects: inbound rules serve the Ingress Controller, while route rules serve the Ingress Gateway.

Once the listening is set up in the ingress gateway, the gateway will monitor traffic from specified domains and ports in real-time. The route rules can forward the incoming traffic to backend instances as desired.

#Example HTTPRoute custom resource (CR)

# example-httproute.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  namespace: k-1
  name: example-http-route
  annotations:
    cpaas.io/display-name: ""
spec:
  hostnames:
    - developer.test.cn
  parentRefs:
    - kind: Gateway
      namespace: k-1
      name: test
      sectionName: demo-listener
  rules:
    - matches:
        - path:
            type: Exact
            value: "/demo"
      filters: []
      backendRefs:
        - kind: Service
          name: test-service
          namespace: k-1
          port: 80
          weight: 100

#Creating Route by using the web console

1. Access the Container Platform.

2. In the left navigation bar, click Network > Route Rules.

3. Click Create Route Rule.

4. Follow the instructions below to configure some parameters.

   Parameter	Description
   Route Type	The currently supported route types are: HTTPRoute, TCPRoute, UDPRoute. Tip: HTTPRoute supports publishing to HTTP and HTTPS protocol listeners.
   Publish to Listener	In the left selection box, select the created Ingress Gateway, and in the right selection box, select the created Listener. The platform will publish the created route rules to the listener below, enabling the gateway to forward captured traffic to specified backend instances. Note: It is not allowed to publish route rules to a listener that is on port 11782 or has already mounted TCP or UDP routes.
   Match	You can add one or more matching rules to capture traffic that meets the requirements. For example, capture traffic with specified Path, capture traffic with specified method, etc. Note: Click Add; when adding multiple route rules, the relationship between the rules is 'AND', and all rules must be matched to be effective. Click Add Match; when adding multiple groups of route rules, the relationship between the groups is 'OR', and any group matching can be effective. TCPRoute and UDPRoute do not support configuring match rules. When the matching object is path, and the matching method is Exact or PathPrefix, the input value must start with "/" and disallow characters like "//", "/./", "/../", "%2f", "%2F", "#", "/..", "/." etc.
   Action	You can add one or more actions to process the captured traffic. Header: The header of the HTTP message contains much metadata that provides additional information about the request or response. By modifying header fields, the server can influence how the request and response are processed. Redirect: The matched URL will be processed in the specified manner, then the request will be initiated again. Rewrite: The matched URL will be processed in the specified manner, then the request will be redirected to a different resource path or filename. Note: Click Add; when adding multiple action rules, the platform will execute all actions in order based on the displayed sequence of the rules. TCPRoute and UDPRoute do not support configuring action rules. Within the same route rule, there cannot be multiple Header type actions with the same value. Within the same route rule, only one type of either Redirect or Rewrite, and only one mode of either FullPath or PrefixPath can exist. If you wish to use the PrefixPath operation, please first add a matching rule of PathPrefix mode.
   Backend Instance	After the rule takes effect, it will forward to the backend instance according to the selected internal routes and ports in the current namespace. You can also set weights, with higher weight values resulting in a higher probability of being polled. Tip: The percentage next to the weight indicates the probability of forwarding to that instance, calculated as the ratio of the current weight value to the sum of all weight values.

5. Click Create.

#Creating Route by using the CLI

kubectl apply -f example-httproute.yaml