什么Azure Kubernetes(AKS)'超时'碰巧断开群集中Pod的连接？

Question

我有一个工作群集服务,所有服务都响应安装在Azure AKS上运行的Ingress nGinx掌舵.这最终是Azure特定的.

我的问题是:为什么我与此群集中的服务/ pod的连接会定期被切断(显然是通过某种空闲超时),为什么该连接断开似乎也与我的Az AKS Browse UI连接被切断一致？

这是为了获得最终答案,以确定触发导致本地"浏览"代理UI与我的群集断开连接的超时(更多背景为什么我要求遵循).

从Az CLI使用Azure AKS时,您可以使用以下命令从终端启动本地浏览UI:

az aks browse --resource-group <resource-group> --name <cluster-name>

这工作正常,弹出一个看起来像这样的浏览器窗口(yay):

在您的终端中,您将看到以下内容:

1. 代理在http://127.0.0.1:8001/上运行按CTRL + C关闭隧道...
2. 转发自127.0.0.1:8001 - > 9090转发自
3. [:: 1]:8001 - > 9090处理8001的连接处理8001处理连接8001的连接

如果您将与群集的连接空闲几分钟(即,您不与UI交互),您应该看到以下打印以指示连接已超时:

E0605 13:39:51.940659 5704 portforward.go:178]丢失了与pod的连接

我仍然不明白的一件事是,群集内的其他活动是否可以延长此超时时间,但无论您何时看到上述内容,您基本上都处于相同的位置...这意味着我们可以谈论它看起来的事实就像我所有的其他连接一样,来自该服务器中的pod的OUT也被任何超时过程关闭,该过程负责切断与AKS浏览UI的联系.

那么问题是什么？

这对我来说是个问题的原因是我有一个服务运行Ghost Blog pod,它使用名为'Knex'的npm包连接到远程MySQL数据库.碰巧新版本的Knex有一个bug(尚未解决),如果Knex客户端和远程数据库服务器之间的连接被切断并需要恢复 - 它不会重新连接,只是无限制负载.

nGinx错误503网关超时

在我的情况下导致nGinx Ingress给我一个Error 503 Gateway超时.这是因为在空闲超时切断Knex连接后Ghost没有响应 - 因为Knex无法正常工作并且没有正确恢复与服务器的断开连接.

精细. 我回滚了Knex,一切都很好.

但是为什么我的pod连接从我的数据库中被切断开始呢？

因此,这个问题希望能够节省一些未来的人们试图解决与Kubernetes(可能是Azure特定的,可能不是)相关的幻像问题的日子,这些问题在服务/ pod已经闲置一段时间之后切断了连接.

Answer 1

简短答案：

当您添加新的入口（nGinx / Traefik ... ANY入口）时，Azure AKS自动部署Azure负载平衡器（具有公共IP地址）-该负载平衡器将其设置配置为具有4分钟的“基本” Azure LB空闲连接超时。

空闲超时既是标准的也是必需的（尽管您可以修改它，请参见此处：https : //docs.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout）。话虽这么说，对于从负载均衡器IP向外向外发送的任何流量，都无法完全消除它-当前支持的最长持续时间为30分钟。

没有本机Azure方式可以解决空闲连接被切断的问题。

因此，按照最初的问题，最好的方法（我认为）是将超时保留为4分钟（因为无论如何它都必须存在），然后设置基础结构以优美的方式断开连接（空闲时）在达到负载均衡器超时之前。

我们的解决方案

对于我们的Ghost博客（命中MySQL数据库），我能够如上所述进行回滚，这使Ghost进程能够处理数据库断开/重新连接的情况。

那Rails呢？

是的 同样的问题。

对于单独的基于Rails的应用程序，我们还在AKS上运行，该AKS连接到远程Postgres DB（不在Azure上），我们最终通过以下方式将PGbouncer（https://github.com/pgbouncer/pgbouncer）实现为集群中的其他容器在这里找到了很棒的指示：https : //github.com/edoburu/docker-pgbouncer/tree/master/examples/kubernetes/singleuser

通常，任何尝试从AKS访问远程数据库的人都可能需要实现中间连接池解决方案。池化服务位于中间（对我们而言是PGbouncer），并跟踪连接空闲了多长时间，因此您的工作进程无需担心。

如果您开始接近负载均衡器超时，则连接池服务将丢弃旧的连接，并建立一个新的新连接（重置计时器）。这样，当您的客户端通过管道发送数据时，它便按预期方式降落在数据库服务器上。

在结束时

这是一个令人沮丧的错误/案例，需要跟踪。我们花了至少2天的开发时间才能确定出第一个解决方案，但是即使知道这可能与我们这次又烧2天的问题相同。

即使将计时器延长到默认的4分钟以上也无济于事，因为那只会使问题更容易解决。我想我只是希望，从Azure AKS / Kubernetes连接到远程数据库时遇到问题的任何人都比我更好地使用Google谷歌搜索，并且可以避免一些麻烦。

感谢MSFT的支持（克里斯，您是最好的），它为LB计时器提供了提示，并感谢花花公子将PGbouncer放在一个容器中，因此我不必重新发明轮子。