有主机和无主机的入口 [英] 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

在分配主机(例如-主机:aws-dsn-name.org )后，此操作将无效.将路径更改为 path:/v1/时，它也不起作用:(.

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?

此外，何时使用 extensions/v1beta1 或 networking.k8s.io/v1beta1

推荐答案

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. 您共享的代码段称为单个后端或

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.

主机条目；只要您的DNS将 aws-dns-name.org 解析为群集中某个节点的IP或主机， aws:dns-name.org 就应该可以正常工作.LB位于群集的前面.对该DNS条目执行ping操作，查看其是否正确解析为目标IP.尝试 curl -H'Host:aws-dns-name.org'IP_Address 来验证入口是否正确响应.NGINX使用 Host 标头来确定要使用的后端服务用.如果您使用其他 Host 条目将流量发送到IP，则它将无法连接到正确的服务，并且将为默认后端.

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.

如果您正在基于路径的路由，也可以与基于主机的路由结合使用，NGINX将根据截获的路径路由到正确的后端服务.但是，就像其他反向代理一样，它将请求发送到指定的路径(http://service:80/v1/).您的应用程序可能未在/v1/路径上侦听，因此您最终会得到404.使用 rewrite-target 注释使NGINX知道您在服务>/.

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 /.

API资源版本确实可以在K8中切换，并且很难跟上.现在正确的注释是 networking.k8s.io/v1beta1 ( networking.k8s.io/v1 从1.19开始)，即使旧版本正在运行，但最终将停止运行.我看到集群升级破坏了应用程序，因为有人忘记更新API版本.

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.

这篇关于有主机和无主机的入口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！