When specifying ingress-class as empty, 'alb' .spec.ingressClassName is still required on ingress definition

[edr-devops]

Describe the bug According to the documentation, if ingress-glass argument is left empty, the controller should take action on any ingress defined on the cluster, however i am not seeing that behaviour.

I believe it is because since 2.2.0 the default ingressClass is set as 'alb'. https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/pkg/config/ingress_config.go#L10

I maybe misunderstanding the logic but passing --ingress-class="", or not passing the --ingress-class argument seems to still require that spec.ingressClassName: alb is still required on ingresses.

Prior to 1.2.0, the ingress controller successfully creates targetGroupBindings for those ingresses without the .spec.ingressClassName. (or ingress-class annotation). The code for 2.1.3, has a default value of "" - https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/v2.1.3/pkg/config/ingress_config.go#L8.

I maybe doing something wrong, so apologies in advance if that is the case.

Steps to reproduce Deploy controller with no --ingress-class specified, and create an ingress within spec.ingressClassName (or deprecated annotation).

Expected outcome With no ingress-class specified, the controller should try to create targetGroupBindings for ingresses without a .spec.ingresClassName defined.

Environment AWS EKS 1.20+

• AWS Load Balancer controller version 1.2.0+
• Kubernetes version 1.20+.

[oliviassss]

Hi, we changed the default value of ingress class from "" to "alb" because we'd encourage the usage of IngressClass and deprecate kubernetes.io/ingress.class annotation via flag--disable-ingress-class-annotation, which requires a non-empty ingress class setting. Any specific reason why you don't want to use spec.ingressClassName ?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[oliviassss]

@edr-devops, I'm closing this issue as for now, please feel free to reach out or reopen if you have any questions. Thanks.