Ignoring ingress when migrating to 1.0.4

[jesussancheztellomm]

NGINX Ingress controller version: v1.0.4

Kubernetes version (use kubectl version): v1.21.4-gke.1801

Environment:

• Cloud provider or hardware configuration: GKE

• OS (e.g. from /etc/os-release): Container-Optimized OS from Google

• Kernel (e.g. uname -a): 5.4.120+

• How was the ingress-nginx-controller installed: Helm chart version 4.0.6

What happened:

I am having problems with my ingress objects after migrating to 1.0.4

All my ingress resources are ignored by the controller

"Ignoring ingress because of error while validating ingress class" ingress="kafka-lab-01/kafka-lab-01-kafka-oauth-0" error="ingress class annotation is not equal to the expected by Ingress Controller"

All those ingress resources have set the annotation

kubernetes.io/ingress.class: kafka-nginx

And i have the following ingressClass

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: kafka-nginx
spec:
  controller: k8s.io/kafka-nginx

The controller is running with the following options

args:
              - /nginx-ingress-controller
              - --publish-service=$(POD_NAMESPACE)/nginx-ingress-kafka-ingress-nginx-controller
              - --election-id=ingress-controller-leader
              - --controller-class=k8s.io/kafka-nginx
              - --configmap=$(POD_NAMESPACE)/nginx-ingress-kafka-ingress-nginx-controller
              - --validating-webhook=:8443
              - --validating-webhook-certificate=/usr/local/certificates/cert
              - --validating-webhook-key=/usr/local/certificates/key
              - --ingress-class-by-name=true
              - --enable-ssl-passthrough

What you expected to happen:

Ingress objects should not be ignored

[k8s-ci-robot]

@jesussancheztellomm: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

Please provide the info requested in the issue template

[longwuyuan]

/remove-kind bug /kind support /triage needs-information

[jesussancheztellomm]

Added. Thanks @longwuyuan

[ttsakpc]

I feel that I am facing the same issue with 1.0.4 (in K8s 1.20)

I would expect kubernetes.io/ingress.class: kafka-nginx annotation (in your case) to work but it doesn't. If you change it to kubernetes.io/ingress.class: nginx it will work, but if you have multiple ingress-nginx controllers installed, all of them will be racing for this ingress object. The "quick solution" would be to remove the annotation and add spec.ingressClassName: kafka-nginx (in your case) to your ingress objects. If you don't remove the annotation you will get error: annotations.kubernetes.io/ingress.class: Invalid value: "nginx": can not be set when the class field is also set

I install using helm and I would expect that setting controller.ingressClassResource.name=kafka-nginx (following your case) would also add --ingress-class=kafka-nginx in the controller arguments (so that annotation "kafka-nginx" would work) but it doesn't. Is this a bug? If this is not considered a bug, I believe that it should be more clearly explained in the docs.

Adding --set controller.extraArgs.ingress-class=kafka-nginx to helm will give you back the functionality that you expect

more info: https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/#multiple-ingress-nginx-controllers https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1

[AndreaGiardini]

I encountered the same bug on Kubernetes version 1.20

The workaround provided by @ttsakpc worked. Thank you

Adding --set controller.extraArgs.ingress-class=kafka-nginx to helm will give you back the functionality that you expect

[winterhalder]

I want to second the importance of that work-around! Why isn't that in BIG BOLD LETTERS in the docs?!!

[Spritekin]

@ttsakpc Thank you so much!!! this is working now. This is a huge bug... should be fixed or at least added to the docs as @winterhalder suggested.

[steveizzle]

Seems to be fixed in newer version

[henryezeanya]

@ttsakpc Thank you so much for this workaround. I spent almost the entire day trying to figure out what was going wrong as I specified all the right things. This really needs to be fixed.

[longwuyuan]

The code related to this topic is being worked on, yes. But on the other hand, not everything can be categorised under one single umbrella. Please see the migration FAQ in the docs. There will be changes released in the near future released that will give priority to the annotation over the ingressClassName field.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[87abhii]

Any update on the issue

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[ttsakpc]

A note here that kubernetes.io/ingress.class annotation is deprecated and we have to switch to .spec.ingressClassName

[longwuyuan]

@ttsakpc , some projects rely on that annotation and can not use the inigressclassName field. So we are supporting the annotation as well as the field.

[ttsakpc]

@ttsakpc , some projects rely on that annotation and can not use the inigressclassName field. So we are supporting the annotation as well as the field.

nice to know! thank you for this 👍

[ttsakpc]

Also a note that current versions of helm chart (since 4.0.17 I think) provide the parameter controller.ingressClass whose document says:

For backwards compatibility with ingress.class annotation, use ingressClass. Algorithm is as follows, first ingressClassName is considered, if not present, controller looks for ingress.class annotation

So instead of --set controller.extraArgs.ingress-class=kafka-nginx you can (should?) use:

--set controller.ingressClass=kafka-nginx

If you keep using the extraArgs parameter, then two --ingress-class parameters are added on the controller, one with the default --ingress-class=nginx and another one with the configured --ingress-class=kafka-nginx parameter. Not sure if this works as expected (it will if the value of the first parameter is overridden by the second one) or if it breaks. But for a cleaner setup it is best to use controller.ingressClass when installing with helm.

[k8s-triage-robot]

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

This bot triages 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:

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

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.