CODEWITHSUNDEEP
nginxkubernetes-helm
Chris G.
Chris G.

Reputation: 25994

Kubernetes Helm Nginx-ingress is hitting "default backend - 404"

Note, I am still learning Kubernetes and Helm.

Installing nginx-ingress with Helm on a localhost running Docker for Mac(edge) with a Kubernetes cluster.

With the following:

helm install --name my-release stable/nginx-ingress

I get the following reply from curl localhost

default backend - 404

That is good news, but where to go from here. I would like to hit a service/Cluster IP. Normaly in Nginx I would put that in a conf file. In the Helm Chart value I can see that it refers to:

controller:
5     name: controller
6     image:
7       repository: k8s.gcr.io/nginx-ingress-controller
…   
183   enabled: true
184 
185   name: default-backend
186   image:
187     repository: k8s.gcr.io/defaultbackend
188     tag: "1.3"

Do you know how it works?

Upvotes: 1

Views: 1888

Answers (1)

Ryan Dawson
Ryan Dawson

Reputation: 12558

The Ingress concept externalises the configuration of routing rules. Instead of putting them in a conf file that sits with the proxy, the rules are treated as Kubernetes resources that you deploy when you deploy your app. Using the example that @Omer Levi Hevroni pointed at, you could have an Ingress resource that contains this spec in its rules: section:

  - host: api.sample.com
    http:
      paths:
      - path: /
        backend:
          serviceName: hello-world-svc
          servicePort: 8080

This is a host-based rule and would mean that any traffic hitting the ingress controller using the request api.sample.com/ (it assumes that a DNS route points to the ingress controller) should be sent on to the Service hello-world-svc - more specifically to http://hello-world-svc:8080/.

Further Ingress resources could be added or this one expanded to route to different Services based on different requests hosts (e.g. a subdomain like anotherapi.sample.com) or paths (e.g. api.sample.com/specialpath). Both could be used together with a rules spec like:

  - host: subdomain1.example.com
    http:
      paths:
      - path: /path1
        backend:
          serviceName: s1
          servicePort: 80
      - path: /path1
        backend:
          serviceName: s2
          servicePort: 80
  - host: subdomain2.example.com
    http:
      paths:
      - path: /path1
        backend:
          serviceName: s3
          servicePort: 80
      - path: /path2
        backend:
          serviceName: s4
          servicePort: 80

Which would direct http://subdomain1.example.com/path1 to the internal url http://s1:80/path1 etc. If the last part of the internal url (path1 in this case) isn't desirable then the rewrite-target annotation can be used with the nginx ingress controller provided the Ingress resource is annotated as of nginx class.

I suspect you know all of this as the question is from a while ago but I thought it would be helpful to fill in an answer.

Upvotes: 3

Related Questions