#Envoy Gateway Operator

#Understanding Envoy Gateway

#Terminology

• Envoy Gateway is an open-source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway.
• Gateway API is a Kubernetes-official collection of custom resources for declaring routing rules and traffic management policies. Envoy Gateway is one implementation of the Gateway API specification.
• Gateway or gatewayapi/gateway is a CR defined by the Gateway API specification.
• envoy-gateway instance is Envoy Gateway instance and all its related resources running in a Kubernetes cluster.
• envoy-gateway-operator is a helm-operator wrapper around Envoy Gateway and use EnvoyGatewayCtl to simplify the deployment and management of envoy-gateway instance.
• EnvoyProxy is a CR defined by the Envoy Gateway specification, used by envoy-gateway instance to manage envoy-proxy instance.
• envoy-proxy instance is a running deployment which handles incoming traffic.

#Architecture

1. After installing the envoy-gateway-operator, it watches EnvoyGatewayCtl and deploys an envoy-gateway instance along with a default GatewayClass.

2. When you create a Gateway that references this GatewayClass and specifies an EnvoyProxy configuration, the envoy-gateway instance deploys an envoy-proxy instance to handle incoming traffic.

3. HTTP, TCP, or UDP Route resources can then be created and attached to this Gateway to define traffic routing policies.

4. For more granular configuration, you can create ClientTrafficPolicy or BackendTrafficPolicy resources and attach them to routes to implement advanced traffic management features.

#Related custom resources

Envoy Gateway and envoy-gateway-operator introduce additional custom resources that, combined with the Gateway API custom resource, comprehensively control all aspects of gateway deployment and routing policy configurations.

#Gateway API related custom resources

For more details about these resources, please refer to the Gateway API Concepts.

#Envoy Gateway-related custom resources

In the recommended deployment pattern, each Gateway uses .spec.infrastructure.parametersRef to reference its own dedicated EnvoyProxy resource.

This one-to-one mapping allows users to control the Gateway's deployment configuration (replicas, resources, scheduling, etc.) by modifying the corresponding EnvoyProxy resource.

#Operator-related custom resources

We recommend deploying a single envoy-gateway instance via EnvoyGatewayCtl per cluster, which is sufficient for typical use cases.

However, the EnvoyGatewayCtl resource allows you to deploy multiple envoy-gateway instance within the same cluster, enabling more flexible control and isolation for advanced scenarios such as different deployment mode

#Install Envoy Gateway via Envoy Gateway Operator

#Prerequisites

Please ensure that you have read the Understanding Envoy Gateway documentation before proceeding.

#Overview

The envoy-gateway-operator is provided to facilitate advanced management of envoy-gateway instance deployments.

The operational architecture functions as follows:

the envoy-gateway-operator continuously monitors EnvoyGatewayCtl and automatically provisions corresponding envoy-gateway instance deployment, service, etc.

#Installation

#Step 1: Install Envoy Gateway Operator

1. Navigate to Administrator -> Marketplace -> OperatorHub
2. Locate the Alauda build of Envoy Gateway under Networking Category and click Install

#Step 2: Create a Default EnvoyGatewayCtl

1. Navigate to Administrator -> Marketplace -> OperatorHub

2. Locate the Alauda build of Envoy Gateway under Networking Category ,click to Open it.

3. Navigate to the All Instances tab

4. Click Create, then in the displayed dialog box, locate the EnvoyGatewayCtl Instance Type section and click Create

5. The Create EnvoyGatewayCtl page displays the following configuration options:

   Field	Default Value	Description	YAML Path
   Name	cpaas-default	Name of the Envoy Gateway instance	.metadata.name
   Namespace	envoy-gateway-operator	Namespace of the Envoy Gateway instance, each ns could only have one envoygatewayctl	.metadata.namespace
   Replica	1	The replica count of the Envoy Gateway deployment	.spec.controller.replicaCount
   Deploy Ns Mode	ControllerNamespace	Determines whether the gateway deployment is installed in the gateway namespace or the controller namespace, please refer to deployment mode	spec.config.envoyGateway.provider.kubernetes.deploy.type
   Resources	1C1G	The resource requests and limits of the Envoy Gateway deployment	.spec.controller.resources

   Recommendation: Use the default values for typical deployments. Click Create to proceed.

#Configuration Via YAML

You could also apply EnvoyGatewayCtl via yaml.

Default Config:

apiVersion: envoy-gateway.alauda.io/v1
kind: EnvoyGatewayCtl
metadata:
  name: cpaas-default
  namespace: envoy-gateway-operator
spec:
  config:
    envoyGateway:
      provider:
        kubernetes:
          deploy:
            type: ControllerNamespace
        type: Kubernetes
  deployment:
    resources:
      limits:
        cpu: '1'
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 256Mi

Each EnvoyGatewayCtl will create a GatewayClass named as $NS-$NAME, for example envoy-gateway-operator-cpaas-default.

#Advanced Config Via EnvoyGatewayCtl

EnvoyGatewayCtl is essentially the envoy-gateway Helm chart wrapped with helm-operator. Its spec corresponds to the values of the envoy-gateway chart, allowing you to configure various global-level features of Envoy Gateway in one source.

For detailed information about available configuration options, please refer to envoy-gateway-chart-values.

#Backend Routing

For example you can configure backend routing in the EnvoyGatewayCtl spec:

apiVersion: envoy-gateway.alauda.io/v1
kind: EnvoyGatewayCtl
metadata:
  name: cpaas-default
  namespace: envoy-gateway-operator
spec:
  config:
    envoyGateway:
      extensionApis:
        enableBackend: true # Enable backend routing in EnvoyGatewayCtl not the envoygateway configmap
      provider:
        kubernetes:
          deploy:
            type: ControllerNamespace
        type: Kubernetes
  deployment:
    resources:
      limits:
        cpu: '1'
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 256Mi