I'm running two Traefik instances, traefik-internal and traefik-external. These are running in EKS and deployed with Helm. traefik-internal is the default IngressClass via the Helm value ingressClass.isDefaultClass: true.
During my setup for this I saw the option in the chart's values to define labelSelector e.g. providers.kubernetesIngress.labelSelector and providers.kubernetesCRD.labelSelector. I've set these values to "traefik-instance=external" and "traefik-instance=internal" respectively.
My intent behind this was to ensure no Traefik IngressRoute or Kubernetes Ingress ever got picked up by the wrong Traefik instance. A user would need to be intentional and set a label on the their Traefik IngressRoute or Kubernetes Ingress. However, on either a Traefik IngressRoute or Kubernetes Ingress we're always setting spec.ingressClassName and specifying the desired in Traefik instance. In the event it's omitted we default to internal.
My question: Why implement labelSelector if we're explicitly setting spec.ingressClassName?
I noticed in the docs for labelselector it mentions "this applies only to Traefik Custom Resources":
A label selector can be defined to filter on specific resource objects only, this applies only to Traefik Custom Resources and has no effect on Kubernetes
Secrets,EndpointsandServices.
Perhaps using labels is useful to separate out other Traefik CRDs that do not implement something to associate them to a specific instance, like Middleware? I could see this being useful, having a Middleware that I'd only ever want to be used with say traefik-external and by setting the label traefik-instance=external an Ingress for example like below would be unable to leverage it.
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: ext-ratelimit
namespace: edge
labels:
traefik-instance: external
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web01
namespace: web01
labels:
traefik-instance: internal
annotations:
traefik.ingress.kubernetes.io/router.middlewares: edge-ext-ratelimit@kubernetescrd
Thanks for the feedback!