I'm migrating from Ingress to the Gateway API with Envoy Gateway, and I'm still working out where configuration should live. One thing I want to customize is the names of the Envoy proxy pods and Services, along with a few other settings.
My planned setup is roughly one GatewayClass per Gateway, similar to how I previously used separate ingress controllers. Because of that 1:1 relationship, putting the EnvoyProxy configuration on the GatewayClass initially seemed reasonable. However, if I ever attach another Gateway to the same class, settings such as explicit resource names could cause conflicts. A Gateway-level EnvoyProxy configuration also replaces the GatewayClass configuration by default when gateway merging is not enabled.
For this kind of setup, should I put the EnvoyProxy configuration directly on each Gateway? If so, is there any useful configuration that should still be defined on the GatewayClass, or should the class configuration remain empty or minimal?
3 Answers
You can still use the Gateway configuration to establish consistent defaults for each individual deployment. For example, public and internal Gateways might each define their own Service type, load balancer class, and external traffic policy. The public version could use an external load balancer, while the internal version uses an internal one. This keeps those choices explicit without forcing unrelated Gateways to share configuration.
For a strict one-to-one GatewayClass-to-Gateway arrangement, putting EnvoyProxy on the Gateway is probably the cleanest option. GatewayClass settings are intended to apply broadly, while names and other per-proxy tuning belong to the individual Gateway. Since a Gateway-level configuration replaces the class configuration unless merging is enabled, class settings can otherwise become unused configuration that still has to be maintained.
Think of the GatewayClass configuration as shared defaults and the Gateway configuration as an override for one specific Gateway. If several Gateways are expected to share the same behavior, put the common settings on the class. Avoid putting a fixed name there, though, because every Gateway using that class could end up competing for the same resource name.
That makes sense. For my deployments, I usually have only one to five dedicated entry points, so I’m leaning toward defining the complete EnvoyProxy configuration on each Gateway and keeping the GatewayClass minimal.