c# - .Net Core 2.2 HttpClient 是否记得失败的 DNS 查找？

Question

我们正在将 Web 应用程序部署到内部托管的 Windows kubernetes 集群。通过一种我不完全理解的机制（但我认为与问题无关），在部署到 K8s 集群之后，我们的应用程序可以通过一个包含应用程序名称和版本号的 DNS 条目来寻址。

因此，在部署完成之前不会创建确切的 DNS 值。事实上，部署完成后需要一段时间才能寻址。

现在到 .Net Core HttpClient 问题...

（如果相关，相关代码通过 Team City 在 Windows Server 2012 上运行）

我已经使用 .Net Core 2.2 HttpClient（通过 HttpClientFactory）编写了一些代码来轮询应用程序的运行状况检查端点，以了解部署何时完成。目前它在发出任何请求之前会等待一段时间。然后它会定期轮询一段时间（最多 5 分钟），然后放弃。

我遇到的问题是，如果第一个轮询请求发生在 DNS 条目可用之前，它（正确地）失败并出现“不知道这样的主机”异常。但是所有进一步的请求也将失败，并出现相同的异常。

就我而言，最佳选择似乎是等待三分钟。这样做时，对我的应用程序的第一个请求将成功，一切都很好。但是，如果我只等待两分钟，它就会失败，即使我再尝试 5 分钟，它也会继续失败。在我看来，一旦第一个 DNS 失败，我就注定要失败。

奇怪的是，我发现一旦我的轮询失败并放弃，随后对 nslookup 的调用就会成功（从 powershell - 即与 .Net Core 控制台应用程序分开）。但是随后执行了更多代码，这次运行的是 .Net Framework 4.6 代码……而且 DNS 也有问题。

那么我是否可以正确地记住某个地方的 DNS 故障，即使它不是全面的（如 nslookup 成功所证明的那样）？如果是这样，如何强制重试 DNS 查找？

我尝试为有问题的 SocketsHttpHandler 设置 PooledConnectionIdleTimeout 和 PooledConnectionLifetime 值（设置为 20 秒，因为我在重试之间的暂停时间为 30 秒），但这并没有帮助。但即使他们是答案并且我做错了，这也不能解释为什么一个单独的.Net 进程直接运行后会出现同样的问题。

标签： c#.net-coredns