Skip to content
kix docs

Install Envoy Gateway

Install the Envoy Gateway controller and its CRDs with the upstream Helm chart. Then use Kix to create the GatewayClass and Gateway that application packages route through.

This guide assumes Helm is installed and your current Kubernetes context points at the target cluster. Check the Envoy Gateway compatibility matrix before choosing a release for a production cluster.

Install the controller and CRDs

Section titled “Install the controller and CRDs”

Install the pinned chart in envoy-gateway-system:

❱ helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.9.1 --namespace envoy-gateway-system --create-namespace

The default chart installation includes the Gateway API CRDs, Envoy Gateway CRDs, and the controller. If your Kubernetes provider already manages compatible Gateway API CRDs, follow Envoy Gateway’s provider-managed CRD procedure instead of installing a second copy.

Wait for the controller Deployment:

Run in kix-examples/ 
❱ kubectl wait --timeout=5m --namespace envoy-gateway-system deployment/envoy-gateway --for=condition=Available
deployment.apps/envoy-gateway condition met

Add the Gateway resources to Kix

Section titled “Add the Gateway resources to Kix”

The Kix envoy-gateway package creates the GatewayClass and Gateway. Add an instance with the listeners your applications need:

how-to/platform/gateway-cluster.nix (L19–L29)
      instances.gateway-system.gateway = {
        package = packages."envoy-gateway";
        config.listeners = [
          {
            name = "http";
            port = 80;
            protocol = "HTTP";
            allowedRoutes.namespaces.from = "All";
          }
        ];
      };

View source on GitHub ↗

The default controllerName is gateway.envoyproxy.io/gatewayclass-controller, which matches Envoy Gateway. The example permits routes from every namespace. Restrict allowedRoutes.namespaces if only selected namespaces should attach routes.

On kind, configure Envoy Gateway to expose its data plane through a NodePort Service:

how-to/platform/gateway-cluster.nix (L49–L52)
      instances.gateway-system.gateway.config.proxySpec.provider = {
        type = "Kubernetes";
        kubernetes.envoyService.type = "NodePort";
      };

View source on GitHub ↗

kind does not provide a load balancer, so Envoy Gateway’s default LoadBalancer Service cannot receive an address there. The NodePort setting allows the Gateway to become ready. Omit this setting on a cluster where a load balancer assigns addresses to LoadBalancer Services.

Deploy the Kix cluster:

Run in kix-examples/ 
❱ kix deploy how-to-platform-gateway

Verify the installation

Section titled “Verify the installation”

Check the controller-managed resources:

Run in kix-examples/ 
❱ kubectl get gatewayclass,gateway --all-namespaces
NAME                                             CONTROLLER                                      ACCEPTED   AGE
gatewayclass.gateway.networking.k8s.io/gateway   gateway.envoyproxy.io/gatewayclass-controller   True       12s

NAMESPACE        NAME                                        CLASS     ADDRESS        PROGRAMMED   AGE
gateway-system   gateway.gateway.networking.k8s.io/gateway   gateway   192.168.97.3   True         12s

The GatewayClass should report Accepted, and the Gateway should report Programmed. With the kind configuration above, Envoy Gateway reports a kind node address for the Gateway.

If either resource remains unready, inspect its conditions and the controller logs:

❱ kubectl describe gatewayclass gateway
❱ kubectl describe gateway gateway -n gateway-system
❱ kubectl logs -n envoy-gateway-system deployment/envoy-gateway --since=10m