azure - Azure Kubernetes (AKS) 'Time-out' 会发生什么情况会断开集群中 Pod 进出的连接？

Question

我有一个工作集群，其中的服务全部响应在 Azure AKS 上运行的安装了 Ingress nGinx 的 helm 后面。 这最终是 Azure 特定的。

My question is: Why does my connection to the services / pods in this cluster periodically get severed (apparently by some sort of idle timeout), and why does that connection severing appear to also coincide with my Az AKS Browse UI connection getting cut?

这是为了获得最终答案，了解到底是什么触发了超时，导致本地“浏览”代理 UI 与我的集群断开连接(更多背景说明我为什么要求关注)。

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

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

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

在您的终端中，您将看到类似以下内容的内容:

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] lost connection to pod

我仍然不明白的一件事是集群内的其他事件是否可以延长此超时，但无论如何，一旦您看到上面的内容，您基本上就处于我所在的位置...这意味着我们可以讨论这个事实看起来我从该服务器中的 pod 发出的所有其他连接也已被负责切断与 AKS 浏览 UI 联系的任何超时进程关闭。

那么问题是什么？

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

nGinx 错误 503 网关超时

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

很好。我回滚了 Knex，一切都很好。

But why the heck are my pod connections being severed from my Database to begin with?

因此，这个问题有望节省 future 一些人尝试解决与 Kubernetes(可能是 Azure 特定的，也可能不是)相关的虚拟问题的时间，在服务/pod 空闲一段时间后切断连接。

Answer 1

简短回答:

Azure AKS automatically deploys an Azure Load Balancer (with public IP address) when you add a new ingress (nGinx / Traefik... ANY Ingress) — that Load Balancer has its settings configured as a 'Basic' Azure LB which has a 4 minute idle connection timeout.

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

Azure 没有原生方法可以避免空闲连接被切断。

因此，根据最初的问题，(我认为)处理此问题的最佳方法是将超时保留为 4 分钟(因为它无论如何都必须存在)，然后设置您的基础设施以优雅的方式断开连接(在达到负载均衡器超时之前)。

我们的解决方案

对于我们的 Ghost 博客(它访问了 MySQL 数据库)，我能够按照上面提到的方式进行回滚，这使得 Ghost 进程能够处理数据库断开/重新连接的情况。

Rails 怎么样？

是的。同样的问题。

对于一个单独的基于 Rails 的应用程序，我们还在 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 连接到远程数据库时遇到问题的人都比我更擅长谷歌搜索，这样可以减轻自己的痛苦。

感谢 MSFT 支持(Kris，你是最棒的)对 LB 计时器的提示，以及将 PGbouncer 放在容器中的家伙，这样我就不必重新发明轮子了。