Ingress-nginx: Empty $service_name and $service_port variables

Created on 29 Feb 2020  路  15Comments  路  Source: kubernetes/ingress-nginx

NGINX Ingress controller version: 0.30.0

Kubernetes version (use kubectl version): v1.17.2 in kind

What happened:

I am trying to get Linkerd to work with ingress-nginx. Linkerd provides instructions for this, the important annotation to add to the Ingress object being:

    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;
      grpc_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;

This didn't work as expected, and I traced this down to the $service_name and $service_port variables not being filled as expected:

> kubectl ingress-nginx conf | grep -C4 service_name
--
        location / {

            set $namespace      "emojivoto";
            set $ingress_name   "emojivoto";
            set $service_name   "";
            set $service_port   "";
            set $location_path  "/";

            rewrite_by_lua_block {
--

What you expected to happen:

The $service_name variable being set to web-svc and the $service_port variable being set to 80.

How to reproduce it:

Install the emojivoto sample application and apply the following Ingress object:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: emojivoto
  namespace: emojivoto
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: web-svc
          servicePort: 80
        path: /

Then use the ingress-nginx kubectl plugin to check the nginx config (kubectl ingress-nginx conf | grep -C4 service_name).

Anything else we need to know:

/kind bug

kinbug

All 15 comments

servicePort: 8080

@praseodym please check the ingress controller pod log.
This should not be 80? (from the web.yaml emojivoto yaml)

@praseodym please check the ingress controller pod log.
This should not be 80? (from the web.yaml emojivoto yaml)

You're right, it should be servicePort: 80. Unfortunately that doesn't make a difference: $service_name and $service_port are still empty.

@praseodym please post the pod logs. If that is empty, something should appear there.

@praseodym are you using the sample ingress definition? (or did you create an ingress without host field?)

I created an ingress object without a host field (the definition in the first post is the full object I applied).

Adding a host field to the ingress fixes the problem:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: emojivoto
  namespace: emojivoto
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;
spec:
  rules:
  - host: localhost
    http:
      paths:
      - backend:
          serviceName: web-svc
          servicePort: 80
        path: /

gives:

        location / {

            set $namespace      "emojivoto";
            set $ingress_name   "emojivoto";
            set $service_name   "web-svc";
            set $service_port   "80";
            set $location_path  "/";

            rewrite_by_lua_block {

While it isn't too common to not have a host field defined, it'd still expect that to work or log a warning message if it is not a supported configuration.

While it isn't too common to not have a host field defined, it'd still expect that to work or log a warning message if it is not a supported configuration.

This is a bug, I am just trying to narrow where is located.

@praseodym please test quay.io/kubernetes-ingress-controller/nginx-ingress-controller-amd64:dev

@praseodym please test quay.io/kubernetes-ingress-controller/nginx-ingress-controller-amd64:dev

This fixes the problem, thank you!

Thanks from the Linkerd team, @aledbf!

@aledbf We are still running into this problem. Namely, I have the following resource:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;
      grpc_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:$service_port;
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: backend-one-svc-west
          servicePort: 8888
        path: /test

I find the l5d-dst-override header to be set to ".default.svc.cluster.local:" We are using 0.33.0

@zaharidichev thank you for the report. I will open a PR to fix this issue.

That said, what's the use case for an ingress without a host field? I asked because, without that field, paths cannot be repeated, and accessing an ingress controller by an IP address is not the "correct" approach.

@aledbf

We are having a similar problem even if we have specified the host variable like below. So while using below ingress we get "set $service_name ""; " in the nginx.conf ( so a empty service_anme) and if I remove annotation "nginx.ingress.kubernetes.io/rewrite-target: /" then it works fine and I get "set $service_name "API";"

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: "ingress-api"
  namespace: test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local;
spec:
  tls:
  - hosts:
    - test.io
    secretName: tls-secret
  rules:
    - host: test.io
      http:
        paths:
        - path: /api/v1/
          backend:
            serviceName: api
            servicePort: 80

Is this something you could have a look at?

I stumble upon this while debugging the linkerd annotations for ingress. It seems not that service_port variable is always 80 by default.

I'm using controller version v0.34.1

Was this page helpful?
0 / 5 - 0 ratings