Kubernetes nginx入口控制器不可靠

我需要帮助详细了解ingress控制器,特别是ingress nginx ingress控制器的工作原理。在我看来,它就像一个黑匣子,应该在公共IP上监听,终止TLS,并将流量转发到pod。但这到底是怎么发生的对我来说是个谜。

这里的首要目标是理解,次要目标是解决我面临的一个紧迫问题。

我有一个有五个节点的集群,正在尝试让Jupyterhub应用程序在其上运行。在大多数情况下,它运行良好。我使用了一个非常标准的Rancher RKE设置,带有法兰绒/印花布的网络。节点运行RedHat 7.9,带有iptables和firewalld,以及docker 19.03。

Jupyterhub代理是使用ClusterIP服务设置的(我还尝试了NodePort服务,也可以使用)。我还设置了入口。入口有时有效,但通常不响应(连接超时)。具体来说,如果我删除入口,然后重新部署我的舵图,入口将开始工作。此外,如果我重新启动一个节点,入口将再次开始工作。我还没有确定入口停止工作的情况。

以下是我的相关服务:

kubectl get services
NAME                       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
hub                        ClusterIP   10.32.0.183   <none>        8081/TCP   378d
proxy-api                  ClusterIP   10.32.0.11    <none>        8001/TCP   378d
proxy-public               ClusterIP   10.32.0.30    <none>        80/TCP     378d

这很有效;telnet 10.32.0.30 80的响应与预期一致(当然,仅来自其中一个节点)。我也可以直接远程登录到代理公共播客(我的情况是10.244.4.41:8000)。

这是我的入口。

kubectl describe ingress
Name:             jupyterhub
Labels:           app=jupyterhub
                  app.kubernetes.io/managed-by=Helm
                  chart=jupyterhub-1.2.0
                  component=ingress
                  heritage=Helm
                  release=jhub
Namespace:        jhub
Address:          k8s-node4.<redacted>,k8s-node5.<redacted>
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-jhub terminates jupyterhub.<redacted>
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  jupyterhub.<redacted>
                           /   proxy-public:http (10.244.4.41:8000)
Annotations:               field.cattle.io/publicEndpoints:
                             [{"addresses":["",""],"port":443,"protocol":"HTTPS","serviceName":"jhub:proxy-public","ingressName":"jhub:jupyterhub","hostname":"jupyterh...
                           meta.helm.sh/release-name: jhub
                           meta.helm.sh/release-namespace: jhub
Events:                    <none>

到目前为止,我对这种情况下的入侵的理解是:

流量到达k8s-node4或k8s-node5的443端口。 一些magic(由入口控制器控制)接收该流量,终止TLS,并将未加密的流量发送到pod 8000端口的IP。这是我想更好地理解的部分。

这个黑匣子似乎至少部分涉及了法兰绒/印花布和一些iptables魔法,而且在某些方面显然也涉及到nginx。

使现代化 :与此同时,我发现了导致Kubernetes崩溃的原因:重新启动firewalld。

据我所知,这抹去了所有iptables规则,而不仅仅是防火墙生成的规则。