I'm moving from Ingress to Gateway API with Envoy Gateway. I want custom names for the proxy resources and may have other settings later.
I expect one Gateway per GatewayClass, but might add another Gateway to a class someday. Is there a good reason to put the EnvoyProxy config on the class instead of the Gateway? Do I need any config on the class if I use the Gateway?
For settings that belong to a particular Gateway, putting the EnvoyProxy config there sounds like the cleaner fit. Custom resource names are a good example: you can choose them with that Gateway in mind rather than sharing a class-level choice with a future Gateway.
The tradeoff is that, without MergeGateways, a Gateway-level EnvoyProxy config completely overrides the class-level config rather than just filling in the differences. Keep the required settings together in the Gateway config if you go that route.
I'd think of the class as the place for shared defaults. With one Gateway per class, either scope can make sense. If you add another Gateway later, check whether the shared names and other settings suit both before relying on the class config.
You don't have to add a class-level EnvoyProxy config just to have one. If all your custom settings are specific to the Gateway, leaving them there is a reasonable choice.
Answers are reviewed before publication.
countertop philosopher:
And if the second Gateway needs its own config, remember that the Gateway-level config replaces the class config in the setup described here. It won't simply inherit the shared settings.