9

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

Nick
  • 1,882
  • 11
  • 16
Dan
  • 651
  • 1
  • 14
  • 31
  • 1
    `extensions/v1beta1` is deprecated and won't be available in v1.18. So, you should use `networking.k8s.io/v1beta1`. – Masudur Rahman Aug 18 '20 at 18:52
  • I just check now, the version I am running is v1.18.6 (client) and v1.18.3 (server), it seems `extensions/v1beta1` is working – Dan Aug 18 '20 at 18:58

1 Answers1

10

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.

Faheem
  • 3,429
  • 19
  • 26
  • Thanks Faheen, i just get to know we are using minikube, how ingress work on it? Is it link the minikube is searching for my host (which is my linux machine-ip) and could not find it, which might be the reason for the 2nd question – Dan Aug 19 '20 at 17:45
  • Also if i am not specifying the host, does it mean minikube ip will be take by default, if yes then when i hit using my host ip of linux why it works ?- 1st question. – Dan Aug 19 '20 at 17:49
  • Actually, Ingress would work the same where ever it is. Your networking stack would change things. Minikube is probably creating an internal network on your machine. You can find out your minikube IP by running `minikube ip`. See if it's the same as your host - just as any VM would do. When you export a service on NodePort, it would try to publish it across all interfaces and give you access to localhost:nodeport. – Faheem Aug 19 '20 at 17:55