我有一个工作集群，其中的服务全部响应在 Azure AKS 上运行的安装了 Ingress nGinx 的 helm 后面。这最终是 Azure 特定的。
我的问题是： 为什么我与此集群中的服务/Pod 的连接会定期被切断（显然是由于某种空闲超时），以及为什么该连接切断似乎也与我的 Az AKS Browse UI 连接被切断同时发生？
这是为了获得最终答案，了解到底是什么触发了导致本地“浏览”代理 UI 与我的集群断开连接的超时（更多关于我为什么要求遵循的背景信息）。
从 Az CLI 使用 Azure AKS 时，您可以使用以下命令从终端启动本地浏览 UI：
az aks browse --resource-group <resource-group> --name <cluster-name>
这工作正常并弹出一个浏览器窗口，看起来像这样（是的）：
在您的终端中，您将看到类似以下内容的内容：
如果您将与集群的连接保持空闲几分钟（即您不与 UI 交互），您应该会看到以下打印内容，表明连接已超时：
E0605 13:39:51.940659 5704 portforward.go:178] 失去与 pod 的连接
我仍然不明白的一件事是，集群内的其他活动是否可以延长此超时，但无论如何，一旦您看到上面的内容，您基本上就处于与我相同的位置......这意味着我们可以讨论它看起来的事实就像我从该服务器中的 pod 发出的所有其他连接一样，也已被负责切断与 AKS 浏览 UI 联系的任何超时进程关闭。
这对我来说是一个问题，因为我有一个运行 Ghost Blog pod 的服务，它使用名为“Knex”的 npm 包连接到远程 MySQL 数据库。碰巧，较新版本的 Knex 有一个错误（尚未解决），即如果 Knex 客户端和远程数据库服务器之间的连接被切断并且需要恢复，它不会重新连接，而是无限地连接负载。
在我的情况下，导致 nGinx Ingress 给我错误 503 网关超时。这是因为在空闲超时切断 Knex 连接后 Ghost 没有响应，因为 Knex 无法正常工作并且无法正确恢复与服务器断开的连接。
Fine.我回滚了 Knex，一切都很好。
但到底为什么我的 pod 连接会从数据库断开呢？
因此，这个问题有望节省未来一些人尝试解决与 Kubernetes（可能是 Azure 特定的，也可能不是）相关的虚拟问题的时间，在服务/pod 空闲一段时间后切断连接。
当您添加新入口（nGinx / Traefik ...任何入口）时，Azure AKS 会自动部署 Azure 负载均衡器（具有公共 IP 地址） - 该负载均衡器的设置配置为“基本”Azure LB，具有 4 分钟的时间空闲连接超时。
该空闲超时既是标准的也是必需的（尽管您可以修改它，请参见此处：https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout）。话虽如此，对于从负载均衡器 IP 向外发送的任何流量，无法完全消除它 — 当前支持的最长持续时间是 30 分钟。
Azure 没有原生方法来避免空闲连接被切断。
因此，根据最初的问题，（我认为）处理此问题的最佳方法是将超时保留为 4 分钟（因为它无论如何都必须存在），然后设置您的基础设施以优雅的方式断开连接（空闲时）在达到负载均衡器超时之前。
对于我们的 Ghost 博客（它访问了 MySQL 数据库），我能够如上所述进行回滚，这使得 Ghost 进程能够处理数据库断开/重新连接的情况。
是的。同样的问题。
对于一个单独的基于 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 放在容器中的家伙，这样我就不必重新发明轮子了。
