Charts: [stable/nginx-ingress] service selector doesn't match ingress controller labels

Created on 18 Mar 2020  路  4Comments  路  Source: helm/charts

Describe the bug
Getting an error: "Connection refused" when trying to access nginx-ingress' external IP (using its type LoadBalancer service).
This functionality was working in nginx-ingress chart version 1.33.5 and broke in 1.34.0.

Version of Helm and Kubernetes:
GKE version 1.14.10-gke.17
helm v3.0.1

Which chart:
stable/nginx-ingress 1.34.0 0.30.0

What happened:
When installing stable/nginx-ingress 1.34.0 on GKE using a load balancer type service (nginx-ingress-controller and/or the default-backend), the service does not have any endpoints. This is because the pods' labels for the controller and the backend have changed while the service selector (on both services) did not.

It seems that the issue is a result of https://github.com/helm/charts/pull/21361.
The pod's labels (both for DaemonSet and Deployment was changed from:
component: "{{ .Values.controller.name }}"
to
app.kubernetes.io/component: controller

The problem is that the Service selector did not change to match the above label.
Result: no endpoints are available for the service

What you expected to happen:
nginx-ingress-controller should be accessible via the LoadBalancer's external IP.

How to reproduce it (as minimally and precisely as possible):
helm install nginx-ingress -n ingress stable/nginx-ingress

Use a browser to access nginx-ingress-controller via the Service's external IP and you'll get "Connection refused".

Anything else we need to know:
chart version 1.33.5 works correctly:
helm install nginx-ingress -n ingress stable/nginx-ingress --version=1.33.5

Most helpful comment

Is it anything to do with my issue I just opened before you #21507 ?

Yes, the two issues are the same (caused by #21361 ).

All 4 comments

Is it anything to do with my issue I just opened before you #21507 ?

Is it anything to do with my issue I just opened before you #21507 ?

Yes, the two issues are the same (caused by #21361 ).

Confirming the issue - observed it today too. It's not cloud-dependent - the same issue occurs on AWS/EKS.

Waaa. This cost me a day, and some serious sweat in the morning. Thanks for fixing.

Was this page helpful?
0 / 5 - 0 ratings