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

Resource NameOverviewUsage Instructions
Gateway ClassIn the standard Gateway API documentation, the Gateway Class is defined as a template for creating gateways. Different templates can create inbound gateways for different business scenarios, facilitating rapid traffic management.The platform includes dedicated Gateway Classes.
Inbound GatewayThe inbound gateway corresponds to specific resource instances, and users can exclusively utilize all listening and computing resources of this inbound gateway. It is a configuration of routing rules effective for the listener. When external traffic is detected by the gateway, it will be distributed to backend instances according to the routing rules.It can be viewed as a load balancer instance.
Route RuleRoute rules define a series of guidelines for traffic distribution from the gateway to services. The currently standard supported types of routing rules in the Gateway API include HTTPRoute, TCPRoute, UDPRoute, etc.The platform currently supports listening to HTTP, HTTPS, TCP, and UDP protocols.

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 # # [!code callout]
  1. See Gateway Class introduction below.
  2. alb2 name is formatted as {gatewayName}-{random}.
  3. gateway name.

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.

    ParameterDescription
    NameThe name of the inbound gateway.
    Gateway ClassThe 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.
    SpecificationYou can choose the recommended usage scenario based on your needs or customize the resource limits.
    Access AddressThe address of the inbound gateway, which is automatically obtained by default.
    Internal Routing AnnotationUsed 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.

Default Created ResourcesName
ALB2 Type Resourcename-lb-random
Deploymentname-lb-random
Internal Routing
  • name-lb-random
  • name-lb-random-lb-random
Configuration Dictionary
  • name-lb-random-port-info
  • name-lb-random
Service Accountname-lb-random-serviceaccount

Updating Gateways

NOTE

Updating the inbound gateway will cause a service interruption of 3-5 minutes. Please choose an appropriate time for this operation.

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.

    ParameterDescription
    Listener Protocol and PortCurrently 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 NameSelect 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
  1. The available types are: HTTPRoute, TCPRoute, UDPRoute.
  2. Gateway listener name.
NOTE

If there is no matching rule for the Path object in the HTTPRoute type route rule, a matching rule with PathPrefix mode and a value of / will be automatically added.

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.

    ParameterDescription
    Route TypeThe currently supported route types are: HTTPRoute, TCPRoute, UDPRoute.
    Tip: HTTPRoute supports publishing to HTTP and HTTPS protocol listeners.
    Publish to ListenerIn 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.
    MatchYou 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.
    ActionYou 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 InstanceAfter 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