CODEWITHSUNDEEP
kubernetes-ingressnginx-ingress
Dan
Dan

Reputation: 741

Ingress with and without host

It is really getting hard to understand and debug the rules for ingress. Can anyone share a good reference?

The question is how the ingress works without specifying the host?

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      annotations:
         nginx.ingress.kubernetes.io/force-ssl-redirect: \"false\"
      name: my-app
    spec:
      rules:
        http:
          paths:
          - backend:
            path: /
              serviceName: my-app
              servicePort: http

Upon assigning a host (e.g.- host: aws-dsn-name.org) it doesn't work. Upon changing the path to path: /v1/ it also doesn't work :( .

How can I debug/check whether the mapping is correctly done?

Additionally, when to use extensions/v1beta1 or networking.k8s.io/v1beta1

Upvotes: 9

Views: 30847

Answers (1)

Faheem
Faheem

Reputation: 3569

There is pretty good documentation available here for getting started. It may not cover all aspects but it does answer your questions. Ingress controller is basically a reverse proxy and follows similar ideas.

  1. The snippet you have shared is called single backend or single service ingress. / Path would be default. It's the only entry so every request on the exposed port will be served by the tied service.

  2. Host entry; host: aws-dns-name.org should work as long as your DNS is resolving aws-dns-name.org to the IP of a node in the cluster or the LB fronting the cluster. Do a ping to that DNS entry and see if it's resolving to the target IP correctly. Try curl -H 'Host: aws-dns-name.org' IP_Address to verify if ingress responding correctly. NGINX is using Host header to decide which backend service to use. If you are sending traffic to IP with a different Host entry, it will not connect to the right service and will serve default-backend.

  3. If you are doing path based routing, which can be combined with host based routing as well, NGINX will route to the correct backend service based on the intercepted path. However, just like any other reverse proxy, it will send the request to the specified path (http://service:80/v1/). Your application may not be listening on /v1/ path so you will end up with a 404. Use the rewrite-target annotation to let NGINX know that you serving at /.

  4. API resources versions do switch around in K8s and can be hard to keep up with. The correct annotation now is networking.k8s.io/v1beta1 (networking.k8s.io/v1 starting 1.19) even though the old version is working but eventually will stop working. I have seen cluster upgrades break applications because somebody forgot to update the API version.

Upvotes: 11

Related Questions