Configuring Envoy Deployments

Envoy Gateway gives you full control over how the Envoy deployments it manages look: their pod and service specs, resource requests, etc. You can even go as far as providing your own custom Envoy bootstrap config. Achieving this is a two-part process: first we need to create a config.gateway.envoyproxy.io/v1alpha1.EnvoyProxy resource describing how a set of Envoys should be deployed, then we need to update our GatewayClass to include a parametersRef to the EnvoyProxy resource we created.

Defining an EnvoyProxy Resource

Envoy Gateway gives you complete control over how it deploys Envoys, and provides the EnvoyProxy CRD for configuring it. Broadly speaking, there are four sections that you can configure:

• logging: how Envoy itself logs, and the log levels of each of Envoy's internal components. See an overview on envoyproxy.io.
• telemetry: how Envoy produces access logs at runtime; their format and output location. See our overview on access logs.
• bootstrap: a custom Envoy bootstrap config
• provider: how Envoy is instantiated

For this example, provider is the most interesting. It lets us tune parameters like the replica count, pod security context, affinities, volume mounts, the Envoy container to be instantiated, what type of Service is instantiated, and more. See Envoy Gateway's reference docs for a full overview, as well as a range of examples configuring various properties.

A simple configuration changing the default Envoy container deployed could look like:

apiVersion: config.gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: custom-proxy-config
  namespace: envoy-gateway-system
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyDeployment:
        container:
          image: envoyproxy/envoy:v1.25-latest

Referencing the EnvoyProxy in a GatewayClass

With our custom EnvoyProxy config defined, we can reference it in our GatewayClass definition. All Gateways that reference this GatewayClass will be re-deployed so that their Envoys are configured as described in the EnvoyProxy config.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  parametersRef:
    group: config.gateway.envoyproxy.io
    kind: EnvoyProxy
    name: custom-proxy-config
    namespace: envoy-gateway-system

That's correct: after re-applying, Envoy Gateway will handle redeploying any necessary Envoy deployments to update them per the intent of the EnvoyProxy configuration.

Next Steps

Read more in our admin section about using the EnvoyProxy resource to:

• enable Envoy debug logging for troubleshooting Envoy itself with the logging section
• configure Application Access Log formats with the telemetry section.

The bootstrap and provider sections are best covered via their reference docs on the official Envoy Gateway site.