Dynamic use of EnvoyProxy..envoyDeployment.pod.topologySpreadConstraints.labelSelector in a GatewayClass?

[Skaronator]

Hi, I am trying to configure topologySpreadConstraints at the GatewayClass level. However, the topologySpreadConstraints feature requires a labelSelector to function correctly. The challenge is that, when applied to GatewayClass, some label values need to be dynamic.

For instance, I’d like to use the same labelSelector as the Deployment resource, which looks like this:

    matchLabels:
      app.kubernetes.io/component: proxy
      app.kubernetes.io/managed-by: envoy-gateway
      app.kubernetes.io/name: envoy
      gateway.envoyproxy.io/owning-gateway-name: private
      gateway.envoyproxy.io/owning-gateway-namespace: network

The issue is that the labels gateway.envoyproxy.io/owning-gateway-name and gateway.envoyproxy.io/owning-gateway-namespace are dynamically set by the corresponding Gateway, not the GatewayClass.

Is there a way to handle this? Ideally, the CRD should use the same labelSelector as the default for the Deployment. If users need customization, they should be able to specify an empty object or define their own labels.

[arkodg]

you could set a common label for all generated deployments using the EnvoyProxy resource

• https://gateway.envoyproxy.io/docs/tasks/operations/customize-envoyproxy/
• https://gateway.envoyproxy.io/docs/api/extension_types/#kubernetespodspec

This is also possible using the infrastructure field on the Gateway resource https://gateway-api.sigs.k8s.io/guides/infrastructure/ which

[Skaronator]

Thank you for the response and the helpful links. I understand that it's possible to create a separate EnvoyProxy configuration for each Gateway with the appropriate labelSelector. However, this approach feels somewhat counterintuitive.

In the vast majority of use cases, it seems more practical for the labels to be inherited directly from the Deployment by default. It would greatly simplify configuration if this were the default behavior. Alternatively, introducing a property to explicitly enable label inheritance could be a valuable enhancement for flexibility.

[arkodg]

you could create one EnvoyProxy and attach it to the GatewayClass as well