排查 Azure Kubernetes 服务（AKS）中标准负载均衡器的 SNAT 端口耗尽问题

如果您知道您正在建立与同一目标 IP 地址和端口的多个出站 TCP 或 UDP 连接，并且您观察到出站连接失败，或者支持人员通知您 SNAT 端口已耗尽，那么您有几个常规的缓解选项。 查看这些选项，确定最适合自己的方案的选项。 一个或多个选项可能有助于管理方案。 有关详细信息，请查看 出站连接故障排除指南。

SNAT 耗尽的根本原因通常是建立和管理出站连接的方式出现了对立模式，或者可配置的计时器已更改，不再使用默认值。

本文可帮助排查在 Azure Kubernetes 服务（AKS）中使用标准负载均衡器时 SNAT 端口耗尽问题。

排查 SNAT 端口耗尽问题的步骤

使用以下步骤排查 SNAT 端口耗尽问题：

1. 检查连接是否长时间处于空闲状态，以及是否依靠默认的空闲超时释放该端口。 如果是，可能需要为你的方案减少 30 分钟的默认超时。
2. 调查应用程序如何创建出站连接（例如：代码评审或数据包捕获）。
3. 确定此活动是否为预期行为，或者应用程序是否行为异常。 使用 Azure Monitor 中的 指标 和 日志 来证明你的发现。 例如，对 SNAT 连接指标使用“失败”类别。
4. 评估是否遵循适当的 设计模式 。
5. 评估是否应通过 更多出站 IP 地址和分配的出站端口来缓解 SNAT 端口耗尽问题。

SNAT 端口耗尽设计模式

尽量利用连接重用和连接池。 这些模式有助于避免资源耗尽问题，并使行为可预测。

• 原子请求（每个连接一个请求）是一个通常并不良好的设计选项。 这种反模式会限制缩放，降低性能并降低可靠性。 应该重复使用 HTTP/S 连接来减少连接数和关联的 SNAT 端口数。 由于使用 TLS 时可以减少握手次数、系统开销以及加密操作的开销，因此应用程序规模与性能都会提高。
• 如果你使用的是群集/自定义 DNS，或者 coreDNS 上的自定义上游服务器，请记住，当客户端不缓存 DNS 解析器结果时，DNS 可以在卷上引入许多单独的流。 请确保首先自定义 coreDNS 而不是使用自定义 DNS 服务器，并定义合适的缓存值。
• UDP 流（例如 DNS 查找）在空闲超时期间分配 SNAT 端口。 空闲超时越长，SNAT 端口上的压力越大。 使用较短的空闲超时（例如 4 分钟）。
• 使用连接池来调整连接卷。
• 切勿以静默方式丢弃 TCP 流，且不要依赖 TCP 计时器来清理流。 如果不允许 TCP 显式关闭连接，中间系统和终结点上将保持已分配状态，使 SNAT 端口不可用于其他连接。 此模式可能会触发应用程序故障和 SNAT 耗尽。
• 在对造成的影响了解不深的情况下，请不要更改与 OS 级别的 TCP 关闭相关的计时器值。 当某个连接的终结点不符合预期时，尽管 TCP 堆栈会恢复，但应用程序的性能可能会受负面影响。 希望更改计时器往往意味着底层设计出现了问题。 查看以下建议：

后续步骤

若要详细了解 AKS 标准负载均衡器配置选项，请参阅 在 AKS 中配置公共标准负载均衡器。