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.
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:
EnvoyProxy in a
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
That's correct: after re-applying, Envoy Gateway will handle redeploying any necessary Envoy deployments to update them per the intent of the
Read more in our admin section about using the
EnvoyProxy resource to:
- enable Envoy debug logging for troubleshooting Envoy itself with the
- configure Application Access Log formats with the