#Configure GatewayAPI Gateway

#Prerequisites

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

#Configuration Via Web Console

1. Navigate to Alauda Container Platform -> Networking -> Gateway -> Gateways

2. Click on Create Gateway button

3. In Create Gateway page select envoy-gateway-operator-cpaas-default under GatewayClass, it will display the following configuration options:

   Field	Description	YAML Path
   Name	name	gateway: .metadata.name envoygateway: .metadata.name
   GatewayClass	which GatewayClass it uses	gateway: .spec.gatewayClassName
   Service Type	service type	envoygateway: .spec.provider.kubernetes.envoyService.type
   Service Annotation	service annotation	envoygateway: .spec.provider.kubernetes.envoyService.annotations
   Resource Limits	deployment resource limits	envoygateway: .spec.provider.kubernetes.envoyDeployment.container.resources
   Replicas	deployment replicas	envoygateway: .spec.provider.kubernetes.envoyService.replicas
   Node Labels	deployment node labels	envoygateway: .spec.provider.kubernetes.envoyService.nodeSelector
   Listener	listener	gateway: .spec.listeners

   WARNING

   The Web Console form only supports GatewayClasses created by EnvoyGatewayCtl. For other GatewayClasses, use the YAML editor.

   NOTE

   When using an EnvoyGatewayCtl-created GatewayClass, the Web Console automatically creates a companion envoyproxy resource matching the Gateway's name and namespace.

#Configuration Via YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo
  namespace: demo
spec:
  infrastructure:
    parametersRef:
      group: gateway.envoyproxy.io
      kind: EnvoyProxy
      name: demo
  gatewayClassName: envoy-gateway-operator-cpaas-default
  listeners:
    - name: http
      port: 80
      hostname: a.com
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      port: 443
      hostname: a.com
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: Same
      tls:
        mode: Terminate
        certificateRefs:
          - name: demo-tls
    - name: tcp
      port: 8080
      protocol: TCP
      allowedRoutes:
        namespaces:
          from: Same
    - name: udp
      port: 8080
      protocol: UDP
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: demo
  namespace: demo
spec:
  provider:
    kubernetes:
      envoyService:
        type: ClusterIP
      envoyDeployment:
        replicas: 1
        container:
          imageRepository: registry.alauda.cn:60080/acp/envoyproxy/envoy
          resources:
            limits:
              cpu: '1'
              memory: 1Gi
            requests:
              cpu: '1'
              memory: 1Gi
    type: Kubernetes

#Introduction

#Service Type

Service Type essentially configures how the gateway is exposed. There are three modes: LoadBalancer NodePort and ClusterIP.

#LoadBalancer (Recommended)

The advantage is ease of use, and high-availability load balancing capabilities. To use LoadBalancer, the cluster must have LoadBalancer support, which can be enabled via MetalLB.

#NodePort

The advantage is that it doesn't require any external dependencies.

However, using NodePort has these disadvantages:

• Can only be used in clusters with fewer than 16 nodes, otherwise the gateway status may become abnormal.
• When using NodePort, Kubernetes assigns NodePort port numbers that differ from the service's own ports. You must use the NodePort port number for access, not the service port.
• The service can be accessed via any node IP address in the cluster, which may pose potential security risks

#How to Get The Correct Port When Using NodePort

kubectl get svc -n ${ENVOYGATEWAYCTL_NS} -l gateway.envoyproxy.io/owning-gateway-name=${GATEWAY_NAME} -o=jsonpath='{.items[0].spec.ports[?(@.port==${PORT})].nodePort}'

The output is the NodePort

#ClusterIP

Very convenient if you don't need external exposure.

#Listener

Listener defines the port and protocol for the gateway to listen on. In HTTP or HTTPS protocols, different hostnames can be treated as a different listener.

You cannot create a listener with a conflicting port or protocol or hostname.

You must create at least one listener in the Gateway.

#Listener Support Kind

Each listener supports different route kinds based on its protocol:

When configuring routes, ensure they match the protocol of the listener they'll attach to. For example, you cannot attach an HTTPRoute to a TCP listener.

#Allow Route NS

By default, Routes can only attach to a Gateway in the Same namespace. To allow cross-namespace routing, you need to specify which namespaces are allowed to attach Routes to this Gateway's listener using the Allowed Routes Namespace field.

There are the following options:

• Same: Allow Routes which are in the same namespace, attach to this listener.
• All: Allow Routes which are in any namespace, attach to this listener.
• Selector: Allow Routes which are in the namespaces matched by the selector, attach to this listener.

For more information, please reference attach to gateway create on other ns.

#TLS

By default, you can only use secret created in the same namespace. Otherwise, please refer to use secret create on other ns.

By default, we use Terminate mode. Otherwise please refer to ssl passthrough.

#Hostname

The hostname in a listener is a unique identifier for listeners that have the same protocol. you cannot add or update a conflicting listener in a gateway.

#Intersection Rule For Listener's Hostname And Route's Hostnames

When a request arrives, it is matched against the intersection of the Listener's hostname and the Route's hostnames. Only hostnames in the intersection are used for routing traffic.

#Companion EnvoyProxy

Envoy Gateway provides different granularities for controlling gateway deployments. We recommend creating a dedicated EnvoyProxy resource for each Gateway and referencing it through the Gateway's .spec.infrastructure.parametersRef field.

This one-to-one mapping approach provides better isolation and more granular control over deployment configurations such as replicas, resources, and scheduling constraints.

For other deployment configuration methods, please refer to deployment-mode.

#Image Repository

This is the default value. It will be replaced by the actual image repository of the current cluster, please do not modify it.

#Next Step

Configure GatewayAPI Route