我们在Azure中在Kubernetes（版本1.9.6）群集中运行了许多不同的基于REST的服务。
其中两项服务，假设A和B需要使用REST调用相互通信。通常，类似于以下内容：
Client calls A (original request)
A calls B (request 1)
B calls A (request 2)
A responds to B (request 2)
B responds to A (request 1)
A responds to the original request
以上是典型的交织微服务架构。手动运行docker实例可在我们的本地测试服务器上完美运行。
当我们在Azure上的Kubernetes中运行时，我们会通过Kubernetes＆＃39;在微服务上间歇性地超时（60秒以上）。网络服务。超时后，重复该请求通常会在几微秒内给出正确的响应。
我在这一点上陷入困境，因为我不知道是什么导致这种情况。它可能是动态路由吗？虚拟化网络？ Kubernetes配置？
有什么想法吗？
答案 0 :(得分：1)
所以我也遇到了这个问题。
基本上，AKS上发生某种网络超时，该超时会将所有连接切断到Pod中。正如您所提到的，这会导致看似随机的错误，很难发现错误，因为您只能看到它们一次（因为再次击中相同的服务会导致预期的正确行为）。
此处有关我的问题的更多详细信息： What Azure Kubernetes (AKS) 'Time-out' happens to disconnect connections in/out of a Pod in my Cluster?
在我的情况下，AKS（或潜在的Kubernetes）在一段时间后断开/切断了我的Ghost博客与数据库的连接，但没有通知服务，然后导致与该服务有关的奇怪错误，导致未意识到该服务已断开并且没有能够继续利用预期的可用/打开的连接。
那不是更多背景的解决方案！
我正在辩论是否在Azure AKS GitHub上打开故障单（以及我的支持订阅）以请求更多信息。如果我收到回复，我将更新此答案！
答案 1 :(得分：1)
最后弄清楚了。
Azure负载平衡器/公共IP地址默认有4分钟的空闲连接超时。
基本上，通过负载均衡器运行的所有内容（无论是由Azure AKS Kubernetes Ingress创建还是由其他方式创建）都必须遵守此规定。您可以更改超时，但是无法完全消除超时（最长的空闲超时时间为30分钟）。
因此，有必要实施一个连接池/监视解决方案，该解决方案将跟踪每个连接（通过负载平衡器/公共IP）所经过的空闲时间，然后断开连接/重新创建任何接近4分钟的截止时间。
我们最终通过令人敬畏的指导在{@ 3}上实现了PGbouncer（https://github.com/pgbouncer/pgbouncer）作为Azure AKS / Kubernetes群集上的其他容器的实现：
总的来说，我可以看到需要超时，但是MAN很难进行故障排除。希望这可以节省你们一些时间！
更多详细信息可以在我的完整文章中找到：https://github.com/edoburu/docker-pgbouncer/tree/master/examples/kubernetes/singleuser
答案 2 :(得分：0)
正如您所描述的那样，它可能不是码头工人或kubernetes问题。相反，你应该在A响应B之前检查B是否响应A，如果是，则检查A是否没有响应原始呼叫。
您可以设置日志以查看是否发生这种情况，或者如果您可以在计算机中重现日志，则进行调试。